Call us: 0161 726 5020

Careers | Blog | Contact Us

GreystoneGreystone
  • IT Services
    • Managed Support Services
    • Cyber Security Services
    • Modern Workplace and Intune
    • Microsoft 365
    • IT Director as a Service (ITDaaS)
    • Data Backup and Disaster Recovery
    • Network connectivity and Managed Wi-Fi
    • Virtualisation and Servers
  • Software
    • Consultancy
    • Custom Software Development
    • System Integrations
    • Web Development
  • Cloud
    • What is the Cloud
    • Cloud Consultancy
    • Migration Services
    • Security Services
    • Cost Management
    • Automation
    • Monitoring and Reporting
    • Optimisation
    • Auditing
  • Case Studies
  • About
  • Contact

Careers | Blog | Contact Us

GreystoneGreystone
Greystone
  • IT Services
    • Managed Support Services
    • Cyber Security Services
    • Modern Workplace and Intune
    • Microsoft 365
    • IT Director as a Service (ITDaaS)
    • Data Backup and Disaster Recovery
    • Network connectivity and Managed Wi-Fi
    • Virtualisation and Servers
  • Software
    • Consultancy
    • Custom Software Development
    • System Integrations
    • Web Development
  • Cloud
    • What is the Cloud
    • Cloud Consultancy
    • Migration Services
    • Security Services
    • Cost Management
    • Automation
    • Monitoring and Reporting
    • Optimisation
    • Auditing
  • Case Studies
  • About
  • Contact

Ask the Expert: Why you should implement OpenID Connect (OIDC) and how to do it

18 August 2022 /Posted bygR3yS103
Jake Mundy

Ask the Expert: Why you should implement OpenID Connect (OIDC) and how to do it

We had a problem with our deployment pipelines. It is not that they didn’t work, they did, and have done for years at this point. The problem was the access keys that grant the pipelines access to AWS resources had not been rotated in an exceedingly long time.

The AWS Security advisor had picked up that we had not rotated our access keys within 90 days and informed us with a big friendly red cross.

Deployment History

From here we went over to the IAM (Identity Access Management) – User section and looked at the active key age for some of our pipeline deployment credentials. Which confirmed that the keys had in fact not been rotated within 90 days!

User Credentials

To fix this we could have gone into the IAM user and rotated the users’ access and secret keys, gone over to Bitbucket or GitHub and updated the secret/environment variable, then if we were feeling particularly diligent, we could have created a recurring ticket in our system to perform this tedious action every 90 days from now until the end of time (or more realistically forgotten about it for another year or two and then gone through the entire process again in the future). We knew there had to be a better way to do this without all the toil associated with it, and happily there is.

Step forward OpenID Connect (OIDC). OIDC is an authentication protocol used to verify a user’s identity this can be used with Open Authorisation (OAuth) to provide an authentication layer on top of the authorisation layer from OAuth. Which is fine but how does it help us?

GitHub has a nice description of how “OpenID Connect (OIDC) allows your GitHub Actions workflows to access resources in Amazon Web Services (AWS), without needing to store the AWS credentials as long-lived GitHub secrets.” Which sounds exactly what we want.

To get up and running, we first need to setup the following things in AWS, an identity provider, a role for use by GitHub, and a policy that we will grant to the role.

Firstly, we created an identity provider for GitHub to use to communicate with AWS. This done in the IAM portal – Identity Providers.

  1. Select OpenID Connect as the provider type
  2. Set the provider URL as token.actions.githubusercontent.com
  3. Set the audience to amazonaws.com
  4. Add tags if you need them

Finally, click Add provider

Identity And Access Management (IAM)

Once it is added it should appear in the list of Identity providers.

Identity Providers

Now that the provider is added we need to create a Role that the GitHub action can assume to perform its deployments.

To do this navigate to the IAM portal – Roles and click Create role

Next, select the Trusted entity type Custom trust policy

Picture 5

Once you have clicked Custom trust policy a new code window will appear at the bottom of the screen. We will need to define our custom policy here.

Below are two examples of policies, one with a broad subject and another with a tightly scoped subject.

  1. Set the principal to the arn of the identity provider we created previously.
  2. Set the audience (aud) to be amazonaws.com
  3. Set the subject (sub) to the scope of the request, see below for some examples.

In this example we set the subject to all repositories in our GitHub organisation “repo:GreystoneUK/*”.

Version Control

In this example we have set the subject to reference a specific repository in our GitHub organisation called OIDCExampleRepo and reference only the main branch.

Picture 7

Once the trust policy is defined, click Next

We will then be prompted to select a permissions policy to assign to the role, for our example we will be using the AWSCodeDeployDeployerAccess policy.

Permissions Policies

Once you have selected the appropriate policies click Next

Give the role a name and description (be kind and write a decent description for the admins who come after you).

Select Trusted Entities

Check your trusted entities look correct.

Check you have assigned the correct permission policies and add tags to the role. Then click Create role.

Add Permissions - AWS

Once the identity provider and role are in place, we can start to use them in our GitHub Actions.

📝 This assumes you already have a working GitHub workflow pipeline that needs upgrading and will not go into the details of setting workflows from scratch.

Here is our original workflow file that uses an AWS Access key and Secret key stored as GitHub secrets to authenticate to AWS CodeDeploy to push out our web app.

Code Deployment

We need to update our workflow to add permission to access the OIDC token and update the aws-actions/aconfigure-aws-credentials step to assume the role.

  1. Set permissions for the job/workflow to write to the id-token
  2. Set permissions to for the job/workflow to read the contents of the token
  3. Set configure-aws-credentials step to assume the role we defined previously (referenced by the role arn).
Code Deploy

Once the workflow is updated to use OIDC, we can run the workflow and see if it has worked.

Here we can see the configure aws credentials step set assume role permissions, then the Create CodeDeploy Deployment step successfully created a new deployment using those permissions.

AWS Code Deployment

Here is the corresponding deployment running in AWS CodeDeploy.

Deployment History

Once we have confirmed this is working using OIDC we can remove the AWS_ACCESS_KEY_ID and the AWS_SECRET_ACCESS_KEY from the repository secrets and finally remove the IAM user and their access keys from AWS.

At this point we have successfully updated our workflow from using named IAM users with incredibly old access keys to using very shorted lived assumed credentials for our pipelines.

Links:

Creating a role for web identity or OpenID Connect Federation (console) – AWS Identity and Access Management (amazon.com)

About security hardening with OpenID Connect – GitHub Docs

Latest Blog Posts

Man leaping from one rock to another with sunset

How to Successfully Transition from In House ...

22 April 2025 Comments Off on How to Successfully Transition from In House IT to Managed IT Support
Larger wooden rocket with smaller rockets aside it

The Long Term Value of Outsourcing IT. ...

25 March 2025 Comments Off on The Long Term Value of Outsourcing IT. Why SMEs Thrive with Managed Support.
Man sat at laptop with small green office block

Driving Sustainability Across Business and Technology Operations 

26 February 2025 Comments Off on Driving Sustainability Across Business and Technology Operations 
Multiple office windows

The IT Implications of Employers Moving Employees ...

19 February 2025 Comments Off on The IT Implications of Employers Moving Employees Back to the Office Full Time

What UK SMEs Need to Know to ...

30 January 2025 Comments Off on What UK SMEs Need to Know to Stay Competitive In 2025

Categories

  • Cloud
  • Greystone News
  • IT Security
  • IT Support
  • Management Consulting
  • Networking
  • Servers
  • Software Development
  • Uncategorised

Our Partners

aws partner network

microsoft partner

databarracks

internet central

highlander

mitigate

cyfor

huntress

pax8

Twitter Linkedin

0161 726 5020 | info@greystone.co.uk

Copyright | Cookie Policy | Terms & Conditions | Privacy Policy | Sitemap

Play It Green

Cyber Essentials

Website design by Creative Essence.

We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok