Introduction
With this release, Amazon Elastic Container Service (Amazon ECS) integrates with AWS Private Certificate Authority (CA) and automates the process of issuing, distributing, and rotating certificates, which makes it simple for customers to secure traffic between services without adding extra operational workload. Now Amazon ECS Service Connect customers can encrypt service-to-service communication using Transport Layer Security (TLS) without modifying their application code, as well as without requiring any extra network infrastructure or operating service mesh solutions.
You can enable traffic encryption when at a per-Service Connect enabled service level within an existing namespace. First, you choose an existing or create a new AWS Private Certificate Authority, and then select it in the AWS Management Console, or provide its Amazon Resource Name (ARN) via the command line interface (CLI), to be used with your Amazon ECS Service Connect namespace. This CA is used for signing your certificates and will also be used as the root of trust. By default, Amazon ECS uses an AWS-managed symmetric encryption key to store the private key into customer’s secret manager. Optionally, you can provide your own symmetric keys for compliance reasons.
Solution overview
Let’s take a look at how you can enable using TLS certificates to secure your existing Amazon ECS workloads running Amazon ECS Service Connect.
First, you’ll need to make some decisions on how you want to manage your certificates and encryption keys.
The recommended method is to use AWS Private CA and short-lived certificates. By default, certificate life is seven days and rotate every five days, and running in and using a short-lived certificate operating mode CA can offer significant cost savings over general purpose. Because Service Connect doesn’t support certificate revocation and instead leverages short-lived certificates with frequent certificate rotation, this option works extremely well for most use cases. You also don’t need to configure expiration date and rotation frequency, since Amazon ECS issues certificates with seven-day expiry period and automatically rotates them every five days.
Another option would be to use an existing Subordinate Certification Authority, or to create and configure a new Subordinate CA in AWS Private CA using an on-premises Certificate Authority. You can also provide your own key materials, or you can use an external key store through AWS Key Management Service (AWS KMS). Import your own key into AWS KMS, and then specify the Amazon Resource Name (ARN) of that key in Amazon ECS Service Connect.
Once you’ve decided on how you are going to manage the certificates and keys, enabling TLS with Service Connect is a straightforward process that we’ll For the sake of simplicity and consistency, we’ll build off of the popular blog post written by Channy Yun when Amazon ECS Service Connect launched at re:Invent 2022, which you can review here: Amazon ECS Service Connect Enabling Easy Communication Between Microservices.
Walkthrough
- Choose the Namespace with the Service you’d like to enable traffic encryption for. In this example, the service-connect namespace was created when you created this cluster. Since it holds the service you want to protect, you’ll select that one.
- Next, select the service we’d like to enable traffic encryption for, and select the option for Turn on traffic encryption under the service information to turn on TLS.
- For the Service Connect TLS role, choose an existing role or create a new one. Amazon ECS provides a new managed resource trust policy that outlines the set of permissions required for issuing certificates. For more information about this new policy, see AmazonECSInfrastructureRolePolicyForServiceConnectTLS in the AWS managed policies for Amazon ECS.
- For Signer certificate authority, choose to use an existing certificate authority or to create a new one.
- For Choose an AWS KMS key, choose an AWS owned and managed key, or you could choose a different key. You could also choose to create a new one from here if required.
- Alternately, if you wanted to enable TLS encryption Amazon ECS, you could do so from the AWS Command Line Interface (AWS CLI) directly. All that is needed to add to the JSON payload is the certificate arn for your awsPcaAuthorityArn, your kmsKey, and roleArn of your AWS Identity and Access Management (AWS IAM) role.
Prerequisites
The only prerequisite for enabling TLS encryption is that the services must be using Service Connect for networking. Services using other networking methods won’t have the option to enable TLS encryption in the manner described above.
Conclusion
In this post, we showed you how to protect an existing Service Connect-enabled Amazon ECS service using TLS encryption. Enabling TLS encryption to Amazon ECS Service Connect is a significant addition for customers who need an additional layer of encryption for compliance and regulatory reasons. Some customers prefer service meshes such as AWS App Mesh, which encrypt traffic at the proxy level without making changes to the application code. Alternatively, some customers implement TLS directly within the application code. Implementing TLS directly is challenging due to the complexity of manual certificate issuance, distribution and rotation, which slows down the development. Elastic Load Balancer (ELB) adds infrastructure complexity for inter-service communication, and service meshes usually require significant investments in tooling and technical personnel, driving up the total cost of ownership of customer applications. For more information, please visit the documentation and read the What’s New Post for this release.
Amazon ECS Service Connect is available in all AWS Regions where Amazon ECS and AWS Private CA are available. Amazon ECS Service Connect is fully supported in AWS CloudFormation, AWS CDK, AWS Copilot, and AWS Proton for infrastructure provisioning, code deployments, and monitoring of your services. To learn more, see the Amazon ECS Service Connect Developer Guide.
Give it a try, and please send feedback to AWS re:Post for Amazon ECS or through your usual AWS support contacts.