This article provides instructions on how to obtain a certificate thumbprint for an OIDC provider on AWS in an automated manner. Although this approach was created with EKS in mind, the same approach with work with other OIDC providers.
Recently, I have been working on automating the deployment of an EKS On AWS.
Part of the requirement for this cluster was to enable IAM roles for the Kubernetes Service accounts – providing fine-grained access control. Part of this configuration is the creation of an OIDC provider, which requires the following three pieces of information:
- The OIDC URL;
- Client(s);
- Thumbprint(s).
It is straightforward to retrieve the OIDC URL from your existing EKS Cluster, and the client will be: “sts.amazonaws.com”. However, retrieving the Thumbprint is more of a challenge, requiring custom code. Being someone who is completely averse to hard-coding, I wanted to find a reliable way to:
- Retrieve the Thumbprint using Lambda – removing the need permanent infrastructure;
- Avoid executing local code on our CI/CD pipeline – there lies the route to chaos!
Here was my journey:
Attempt #1
Most of my colleagues use Python so my first attempt was based on that language. I wrote the Python code and got it working on Eclipse. So far, so good.
It had a dependency for pyOpenSSL, which I created as a Lambda layer. I deployed both the Lambda and the Layer to AWS and executed the Lambda. Aaaargh – a dependency nightmare ensued. As it turns out, the Python runtime for AWS Lambda did not have the supporting libraries that pyOpenSSL required, so back to the drawing board!
Attempt #2
Not to be beaten, I turned to the ever-reliable (albeit memory hungry) Java. This time I wasn’t taking any chances, so I downloaded the exact Java 11 runtime that Lambda uses – Amazon Coretto 11, and configured Eclipse with that. This time, I used the standard Java NET libraries to retrieve the Thumbprints for the URL. I published the Lambda and it worked perfectly (celebrated with a coffee – because I’m so rock ‘n’ roll).
The Completed Code
Now that I had a working version in Java, I extended the Java code to:
- Provide SHA1, SHA256, and MD5 encodings of the thumbprints;
- provide the thumbprint for every certificate found in the certificate chain – not solely the root certificate;
- provided documentation for anyone who would like to use or modify the library for their purposes.
This may seem excessive, but I didn’t want to create a single-use library – particularly given the first failed attempt. Given that we need root CA SHA1 Thumbprint for EKS – which is the last certificate in the chain, I created helper functions to identify the first and last certificates within the chain.
How to use the Library
I have published the code in GitHub, and the link can be found here.
The .jar file in the “deploy” folder can be upload to a Java 11 Lambda straight away (note: the Lambda should not be VPC connected – this would necessitate an outbound internet connection and potential additional unnecessary infrastructure).
Once you have created your Lambda, you can test it by creating a test payload as follows:
{ url: "https://oidc.eks.eu-west-1.amazonaws.com" }Note: you will need to replace the region above with the region you require.
This example retrieves the thumbprint for the EKS OIDC provider in EU-WEST-1. However, you can use the Lambda to retrieve thumbprints for any URLs you need.
That’s it! You will retrieve a response with all possible encodings of all certificates in the chain of the specified URL. Because we need to get the Root CA SHA1 thumbprint to configure the EKS OIDC provider, you use the following element from the response to get the correct item:
last.sha1
Note: This article is an opinion and does not constitute advice – any actions taken by a reader based on this article are at the discretion of the reader, who is solely responsible for the outcome of those actions.
