Trouble authenticating your application on EKS through IRSA?
AWS Web Identity Token Authentication in Legacy Applications
How to run make applications without support for AWS web identity token authentication run in environments requiring it
Some applications do not support web identity token authentication, but many of those do support credential process authentication. This story discusses implementing a credential process that can add web identity token authentication to an application without modifying it.
Background
Web identity token authentication
In May 2013, AWS announced the availability of the STS API call AssumeRoleWithWebIdentity. This API call allows users to exchange JWT bearer tokens 🔑 issued by OIDC-compatible identity providers (IdPs) for short-lived AWS role session credentials 🧾. Web identity token authentication is now an essential part of the operation of many services, including all applications running on EKS (Kubernetes) authenticating themselves to AWS through IAM Roles for Service Accounts (IRSA).
Despite its importance in some environments, it is taking a while for applications to implement web identity token authentication. Support for web identity tokens as part of the default credential provider chain ⛓ was added to the AWS Golang SDK in June 2019, six (!) years after AssumeRoleWithWebIdentity was introduced. Although now included in all AWS-supported SDKs, many libraries and applications out there still go without support. Often, these are applications written using an older version of an AWS SDK or written in a language for which an SDK does not exist (R!)— in which case they often do not implement the entire credential provider chain ⛓.
Lack of web identity authentication support can be problematic. When running on EKS and if the application supports metadata service-based authentication, you may be able to fall back to using (coarse-grained) node-based authentication or solutions like kube2iam. This story outlines an alternative approach that works everywhere, as long as the application supports credential process authentication.
Credential Processes
Credential process authentication is one of AWS's oldest and best-supported ways of authenticating. To use it, you configure an AWS profile in ~/.aws/config and point it to an executable:
[default]
credential_process = /path/to/my/executableRunning the executable should print (short-lived) role session credentials 🧾 to stdout in the following format:
{
"Version": 1,
"AccessKeyId": "an AWS access key",
"SecretAccessKey": "your AWS secret access key",
"SessionToken": "the AWS session token for temporary credentials",
"Expiration": "ISO8601 timestamp when the credentials expire"
}Web identity credential process
The idea is to implement a credential process that calls on AssumeRoleWithWebidentity and then prints the resulting role session credentials 🧾 to STDOUT .
It is certainly possible to implement such a process using a combination of the AWS CLI, pipes, and the jq JSON processor. If you want to use this with containerization, a solution that avoids introducing superfluous runtime dependencies is preferable. We can compile a fully functional self-contained binary from the following Golang code:
After compiling this application and installing it, say, to /usr/local/bin/wicp, define a profile referencing it as a credential process:
cat > ~/.aws/profile <<'EOF'
[default]
credential_process = /usr/local/bin/wicp
EOFYour application can now authenticate itself as long as a web identity token 🔑 is available!
The default credential provider chain ⛓ prioritizes using web identity tokens 🔑 (referenced by AWS_WEB_IDENTITY_TOKEN_FILE) over using the default profile. The credential process will, therefore, not recursively call itself. Only applications not supporting web identity token authentication will use the default profile and call on the wicp credential process for credentials.
☞ Crafting HTTP calls to AssumeRoleWithWebIdentity and parsing the XML result yourself results in a smaller binary (which, for me, was irrelevant).
Limitations
Credential process authentication seems more widely supported than web identity token authentication, but some applications support neither. For those applications, this workaround will not work; you must then look at other solutions. This can include metadata-server-based authentication or exposing temporary role session credentials to the environment directly. You may even have to consider the use of long-lived IAM credentials 😱.
