-
Notifications
You must be signed in to change notification settings - Fork 13
docs: secure private access #285
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
::: info | ||
Aklivity recommend using the format `*.<region>.<custom-domain>` for your custom wildcard DNS domain. This removes the need for additional client configuration, as the MSK Serverless cluster region can be directly inferred from the custom domain itself. | ||
::: | ||
Multiple Kafka clients from cross-account VPCs securely connect to a single Amazon MSK Serverless cluster. This approach simplifies multi-tenant access and ensures a unified, private connectivity model. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multiple Kafka clients from cross-account VPCs securely connect to a single Amazon MSK Serverless cluster. This approach simplifies multi-tenant access and ensures a unified, private connectivity model. | |
Multiple Kafka clients from different cross-account VPCs securely connect to a single Amazon MSK Serverless cluster. This approach simplifies multi-tenant access and ensures a unified, private connectivity model. |
Follow the [Secure Private Access with Terraform](https://github.com/aklivity/zilla-plus-aws-templates/tree/main/amazon-msk/cdktf/secure-private-access) guide to generated or deploy a custom Terraform template using [CDKTF](https://developer.hashicorp.com/terraform/cdktf). This Terraform script can be configured to deploy `SASL/SCRAM authentication`, `Mutual TLS (mTLS) authentication` or `Unauthorized access` to setup connectivity to your MSK Serverless cluster with a wildcard DNS pattern. | ||
### One-to-Many Private Access | ||
|
||
Enables Kafka client to securely access multiple Amazon MSK Serverless clusters deployed across different VPCs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Enables Kafka client to securely access multiple Amazon MSK Serverless clusters deployed across different VPCs. | |
Enables Kafka clients to securely access multiple Amazon MSK Serverless clusters deployed across different VPCs. |
|
||
## Deploy with CDK | ||
|
||
Follow the [Secure Private Access with CDK](https://github.com/aklivity/zilla-plus-aws-templates/tree/main/amazon-msk/cdk/secure-private-access) guide to generated or deploy a custom AWS CDK stack. This CDK-based deployment supports `SASL/SCRAM authentication`, `Mutual TLS (mTLS) authentication` or `Unauthorized access` to setup connectivity to your MSK Serverless cluster with a wildcard DNS pattern. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Follow the [Secure Private Access with CDK](https://github.com/aklivity/zilla-plus-aws-templates/tree/main/amazon-msk/cdk/secure-private-access) guide to generated or deploy a custom AWS CDK stack. This CDK-based deployment supports `SASL/SCRAM authentication`, `Mutual TLS (mTLS) authentication` or `Unauthorized access` to setup connectivity to your MSK Serverless cluster with a wildcard DNS pattern. | |
Follow the [Secure Private Access with CDK](https://github.com/aklivity/zilla-plus-aws-templates/tree/main/amazon-msk/cdk/secure-private-access) guide to generate or deploy a custom AWS CDK stack. |
Only IAM authorization is relevant for MSK Serverless clusters, there are no choices like MSK Provisioned clusters.
src/.vuepress/public/one_to_many.png
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This many-to-one scenario requires a different VPC Endpoint for each VPC Endpoint Service, so in this case the Kafka client VPC would have 3 VPC Endpoints, each one leading to a different Zilla Plus NLB.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The label VPC Endpoint Service
should be VPC Endpoint
(in both diagrams).
src/.vuepress/public/one_to_many.png
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The label VPC Endpoint Service
should be VPC Endpoint
(in both diagrams).
No description provided.