DEV Community

Cover image for AWS SSO & GitHub OpenID Connect Setup
John Doyle for AWS Community Builders

Posted on • Updated on

AWS SSO & GitHub OpenID Connect Setup

After setting up our AWS accounts, we need to ensure that only our user and our CI/CD pipeline have permission to perform updates. AWS has published a lot of resources around best practices.

Identity Center

Since we plan to have multiple AWS accounts, we need to manage access to each of them. The AWS Identity Center enables you to create and manage AWS users, groups, and permissions to grant or deny access to AWS resources across AWS accounts in your organizations.

We do not want to access any of our accounts with the root account. Instead, we will create an IAM user with our primary account's AWS Identity Center that will have access to each of the AWS accounts we need.

Similar to how IAM is generally configured, you have a User, who can be assigned to a Group, and that Group can be granted permissions.

As this is across AWS Accounts, the mapping of permissions is configured account by account. So your development group might have full access to the development account, but maybe only read access to CloudWatch logs etc in the production account.

AWS Identity Center Permission Mapping

Single Sign On

Another great feature of AWS Identity Center is that it gives us a personalized URL to sign in with our IAM user and access all the accounts that the user has access to! The portal allows us to either log in to the account or download temporary access credentials for use with the AWS CLI.

Single Sign On URL

Now we login with our user and can get access to which ever account we need:

SSO Access

CI/CD

With our user having access, we start to shift our focus over to our pipeline and CODE! The aim here is to use GitHub Actions to deploy our changes.

It is a bad practice to create an IAM User and use their credentials for our pipeline's permission set. We end up with Access Keys that never get rotated, in an external service. If the Access Key is compromised, it can lead to unauthorized access to your resources, resulting in data breaches, data loss, or other security incidents.

We prevent this by granting GitHub access to assume IAM roles which grants the service temporary credentials to our AWS Account.

Identity Provider

The first step in this configuration is to authorize GitHub as a trusted service. We will perform all of these steps in each AWS account we want GitHub to have access to, so login to the Dev account now.

Once logged in, we can configure create a new Identity Provider. GitHub has provided documentation on setting this up.

Adding Identity Provider

Creating a Role

Now that we have a trusted identity provider, select it from the list and you should have the option to Assign Role to it:

Assign Role

Let's create a new role, and it should pre-populate the role with some options. You will need to select the audience from the drop down, but there should only be one.

Creating Role

Assign the role the permissions we will want the CI/CD Pipeline to have. Don't worry too much about this, we will come back to it often to refine the permissions as we go. Finally set a name like GitHub and create the role.

Restricting the Role

Having a role is great, but we don't want anyone using GitHub to be able to assume it.

We will lock this down to our GitHub Repo and to a specific branch.

Open the Trust Relationships for the role.

Initial Trust Relationships

I will update the Condition statement to only grant access from the dev branch of the github repo:

"Condition": {
   "ForAllValues:StringEquals": {
      "token.actions.githubusercontent.com:ref": "refs/heads/dev",
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
   },
   "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:johncolmdoyle/holycitypaddle-code:*"
   },
}
Enter fullscreen mode Exit fullscreen mode

Production

Now repeat these same steps for the production account and update the condition statement to reference our main branch:

"Condition": {
   "ForAllValues:StringEquals": {
      "token.actions.githubusercontent.com:ref": "refs/heads/main",
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
   },
   "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:johncolmdoyle/holycitypaddle-code:*"
   },
}
Enter fullscreen mode Exit fullscreen mode

We are now ready to utilize configure-aws-credentials within our GitHub Actions as we move onto deploying our code!

Top comments (0)