Storing usernames, passwords, IDs, and secrets within a text-based config file is still common practice practically everywhere. This was a requirement about a decade ago, but now there are better ways to avoid this practice and switch to something more secure.
First step
Grant identity to your VM instances, containers, and functions.
AWS: Attach IAM Instance profiles or IAM roles your EC2 instances, ECS tasks, EKS pods, or Lambda functions.
Azure: Add a system-assigned Managed Identities to, everything. There isn’t a reason why this isn’t the default practice. Do avoid using user-assigned Managed Identities, though.
GCP: Attach user-managed service accounts to anything that supports them.
Once that is done, you can grant permissions to anything running on those VM instances or containers using IAM roles.
Second Step
Work on removing any stored credentials you were using to access services within the cloud environment. Now that the resources have been granted identity directly, they aren’t needed anymore.
AWS: There isn’t anything else to do. The pre-installed agent will maintain a rolling set of temporary access keys that are stored in environment variables.
Azure: You will now need to switch to logging in using identity instead of passing in credentials.
Examples:
- CLI: az login -identity
- Code: Use ManagedIdentityCredential instead of DefaultAzureCredential.
GCP: You don’t need to do anything. The Application Default Credentials will use the assigned service account automatically.
Third Step
Move any remaining secrets to SSM parameter store, Secret Manager, or a KeyVault. Now grant your identity access to the secrets and add some code to your app to pull in the secrets at startup. Now those secrets exist in memory instead of written to disk.
That covers granting access within your cloud environment. Now we are going to expand this practice outside of your cloud’s walled garden.
Workload Identity Federation
Workload Identity Federation is a newer term that represents the ability to allow an internet attached workload to authenticate and access resources provided by another internet attached service or workload using existing identity provided to the workload. In other words, granting access to something outside of your environment, without using a separate set of stored credentials, to access stuff in your environment. The source workload can be a resource in a public cloud, an internet-based software service, or even a custom application running on-premise.
A common example of this is allowing your deployment pipeline (Github, Gitlab, Azure Devops, or Bitbucket) to deploy new resources without having to store a set of credentials. You effectively allow the 3rd party service access to use a role (AWS), app registration (Azure), or service account (GCP) within your cloud environment if certain criteria are met.
It is even possible to use this form of authentication and authorization from either of the three main public clouds (AWS, Azure, and GCP) to each other. I have examples of how this is done if anyone is interested.
OpenID Connect
This new method of workload authentication and authorization makes use of OpenID Connect. OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, that has become the default for authorizing end-users. This new layer allows target platforms to verify the identity of a source user or workload based on the authentication performed by a web service, the Authorization Server. It is accessed by way of a predetermined URL that the is known to the target identity platform. During the process, basic information is passed on to the target platform to aid in verifying the workload’s identity.
With traditional secret based credentials, if they get compromised, they could be used from anywhere in the world. To try and control their use, network restrictions are put in place such as IP address whitelists. Using IP whitelists with public cloud providers is very problematic, bordering on impossible, as all potential IPs are not publicly available or are in a constant state of change.
Workload Identity Federation reduces the need for IP address whitelists for additional network security. This is because the authentication is locked down to the source identity and can’t be used outside of the constraints enforced by the source identity provider. If the identity is directly assigned to a workload, only that workload can use it.
NOTE: Instead of trusting set of shared credentials you will now be trusting the application or workload. Make sure the workload you are trusting is trustworthy.
Warnings
Azure: If you use a shared identity (User-Assigned Managed Identity) then anything with contributor access to the managed identity can generate access tokens and impersonate the identity. If you need to use a shared identity, store it in a separate resource group that only security admins have access to.
GCP: Do not generate user-assigned keys for your service accounts as they will allow others to impersonate the service account. It also completely defeat the original purpose of doing away with credentials.