Skip to content

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

Merged
merged 6 commits into from
Feb 13, 2025
Merged

docs: secure private access #285

merged 6 commits into from
Feb 13, 2025

Conversation

ankitk-me
Copy link
Contributor

No description provided.

::: 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Contributor

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.

Copy link
Contributor

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).

Copy link
Contributor

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).

@ankitk-me ankitk-me merged commit 26aedeb into aklivity:develop Feb 13, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants