The proper way to provide identities to applications on Cloud and container platforms is for the compute platform to provide that identity to the application instance . I call this the Cloud native application identity.
Once the application has received its identity from the compute platform along with an identity document or credential the application can use to prove that identity to others, the application can authenticate with services and interact with them if they are authorized. The most common way of managing the application’s authorization will be through the Cloud’s IAM service.
Example
Let’s work through an example where we have configured a Cloud application deployment to:
- run in a Cloud-managed compute environment such as a virtual machine; this could also be a container or function
- the application’s virtual machine is configured to run with an application-specific ‘Execution’ IAM role, e.g.
ecommerce-frontend; the terms for the ‘Execution’ role in AWS are:- EC2 instance role (profile)
- Container task execution role
- Lambda function execution role
On AWS, plus Azure and GCP with small changes, the process for bootstrapping application identity looks like this:
First, the Cloud compute service (AWS EC2) starts a virtual machine for the application and configures that virtual machine to ‘run as’ the application’s Execution role identity, ecommerce-frontend. As part of provisioning the virtual machine (or container, or function), the compute service deploys a special ‘metadata’ service endpoint in the compute service’s virtual machine hypervisor that is only reachable from the application’s virtual machine. This is possible because Cloud providers run highly-customized hypervisors — this is not vanilla KVM, Xen, or VMWare.
The metadata endpoint contains a lot of information useful to the VM’s startup processes, but perhaps the most important information it contains is an instance identity document. You can think of the identity document as the application instance’s passport, which it will present to other services to access them. Each compute instance gets its own, unique identity document that is associated with the execution IAM role.
The Cloud compute service (EC2) generates this identity document and provides a signs it with its own cryptography keys so that other services can trust it by verifying the chain of signatures includes AWS’s signature using PKCS7. <— This is the important bit.
The Cloud’s compute, identity, and even networking services are a tightly integrated, trusted control plane. You configured the application deployment to run on certain compute instances with a certain identity (IAM execution role) that allows the application access to other resources. The Cloud platform took care of the difficult bit of securely connecting your automated, ephemeral compute instance with the desired application identity. See The First Secret Problem or the State of Application Secret Delivery and Audit Practices for more on why this is a difficult.
Second, startup scripts or the application use the Cloud’s SDK to retrieve short term credentials derived from the compute instance’s identity document.
Third, the application can make requests to services managed by the Cloud that are integrated with the Cloud’s IAM service. These requests are authenticated by the short-term credentials.
When the application constructs a request to e.g. retrieve a file from the S3 Object store, the application signs that request with the short term credentials and includes that signature with the request as http headers. Fortunately, the Cloud’s tools and SDKs (e.g. aws-cli or aws-sdk, botocore, boto3) take care of this mostly transparently, because it’s a complicated process.
When S3, DynamoDB, or another service integrated with IAM receives the application’s request, it authenticates the request by contacting the Cloud’s IAM service to verify that it was signed by an IAM role or user with credentials that are still valid. Once authenticated, the receiving service can work with IAM to determine what actions the principal is authorized to execute.
Notably, Cloud-managed services like S3 are not going to check your firewall rules when making an access control decision (c.f. Zed, authorizing application access via network controls is nearly dead).
If your application only uses services that authenticate via your Cloud’s IAM service, you’re in luck. You can stop here, satisfied knowing that your application never has to handle a long-lived, shared credential.
Unfortunately, most applications don’t get to stop here because they need to talk to third-party APIs and applications.
Fourth, the startup and application scripts can use the short term credentials from Step 2 to retrieve secrets from a Secret Store that knows how to validate the Cloud-provided IAM credentials.
Some secret storage services that can do this effectively with varying implementations are: AWS Secrets Manager, EC2 SSM Parameter Store, S3, Hashicorp Vault, Kubernetes IAM integration, kops, and more.
The ‘third-party’ credentials might include: an API key, a database password, or TLS client certificate. Those credentials might provide access to a specialized data analysis, image recognition, logging, or monitoring, service. See Consuming Secrets in Applications for more on how to do that safely.
Fifth, startup scripts and the application can present the credentials to the third-party service. In this scenario, the ‘third-party’ service effectively means an application a separate security domain. That is, it is not managed by the Cloud nor part of the application deployment. When a Cloud application needs to communicate with services on-premises or in another Cloud, the authentication and authorization problem can look a whole lot like a third-party service.
Takeaways
I hope this has helped you understand the ‘Cloud native’ way applications have identified themselves to both Cloud-managed and third-party services for years. The key takeaways are:
- leverage the identity provided by the Cloud compute platform, e.g. AWS IAM execution role
- leverage the Cloud’s Identity and Access Management service to authorize access to services wherever possible
- bootstrap access to third-party services by retrieving secrets using the application’s Cloud native identity
Hit reply with questions and comments.
The next post in this series will explore some of the nascent ways to identify applications and control access across compute platforms using technologies like service mesh and emerging standards like SPIFFE.
Stephen
#NoDrama
