Previous Making a Difference: Essents role in the Refugee Talent Hub
Next Spotlight on Essenters: Rob van Nistelrooij

Secure deployment to the cloud using OpenID Connect

Ali Habib, Anouk Kieboom
6 minutes
Within Essent, Gitlab CI/CD is widely used. As technical development is moving fast, Essent is continuously moving to keep up to date with the best authentication methods for GitLab CI/CD pipelines, to keep our landscape secure. This article will discuss the different authentication options for GitLab CI/CD and focus on OIDC (OpenID Connect), and how it is used within Essent. In addition, a few arguments will be provided why OIDC is preferred over any other authentication method.

In general, there are multiple options to connect Gitlab CI/CD to AWS (Amazon Web Services):

  • IAM User Credentials
  • Assume IAM role
  • OpenID Connect (OIDC)


IAM USER CREDENTIALS

This option allows the usage of an AWS IAM User with credentials. It is the oldest available authentication method. The AWS Access Key and AWS Secrets Key can be used in a CI/CD pipeline by adding the credentials in the GitLab variables. Unfortunately, this option has a lot of drawbacks. Here are some of the main concerns:

  • Security Risks: Due to the nature of IAM User Credentials the credentials are (generally) long-lived, can be shared and hardcoded. Therefore, exposure of credentials becomes more likely.
  • Lack of Granular Permissions: Managing least-privilege access can be challenging with static credentials. Over time the IAM user tends to acquire over-privileged Access.
  • Management Overhead: Rotation can be complex since the credentials can be used in many places.
  • Compliance Issues: Regulations and compliance standards mandate the use of more secure methods.
Even though there are many drawbacks, there are also benefits in using IAM User credentials:
  • Low Complexity: IAM User Credentials are easy to create and there is a minimal risk of mistakes such as assuming the wrong role.


ASSUME IAM ROLE

This option allows the usage of an IAM Role, which does not use credentials but instead uses AWS Security Token Service (STS). This token allows you to assume a role and obtain temporary security token credentials. Even though this method is more secure than the IAM User Credentials, this approach still has several concerns:

  • Performance: Retrieving temporary security credentials from the instance metadata service can add latency to your application's operations. Though this is usually negligible.
  • Complexity: Proliferation of IAM Roles can lead to complexity of IAM Role management. Therefore, least-privilege access as an objective can be difficult to sustain.
  • Lack of Granular Permissions: Also, as mentioned above, managing least-privilege access can be challenging with an IAM Role, especially in larger organizations.

Although, this approach has some drawbacks, there are also many benefits:

  • Improved Security: Using IAM Roles, you can avoid embedding long-term access keys in your application code.
  • Easier Management: Roles make it easier to manage permissions, because you can attach or detach policies to the role.
  • Automatic Credential Rotation: When you use an IAM role, the AWS SDKs and CLI automatically handle the retrieval and rotation of temporary security credentials. This reduces the risk of credential exposure.
  • Cross-Service Access: Roles can be used to grant permissions, to allow AWS services to access one another. For instance, allowing an EC2 instance to access an S3 bucket.


OPENID CONNECT (OIDC)

OIDC is similar to the IAM Assume Role method. However, there is an additional layer on top. This additional layer allows users to verify the identity of the end-user and obtain basic profile information about the end-user. This additional layer allows you to obtain an access security token based on the Gitlab user identity. This approach has the exact same disadvantages and advantages as the assume IAM Role, as stated above. There are, however, additional advantages to this approach:

  • Security: It utilizes GitLab’s OIDC provider and AWS’s “AssumeRoleWithWebIdentity” method for secure token exchange.
  • Granular Authentication: This method can be used for more precise authorization, because it allows granular permissions based on the origin of the deployment or resource tags. For example, it can be based on specific Branches or repositories.

Because of the security advantages, Essent decided to go with the Gitlab OIDC approach.


GITLAB OIDC IMPLEMENTED BY ESSENT

Integrating GitLab with AWS using OpenID Connect (OIDC) involves setting up GitLab as an identity provider (IdP) and configuring AWS to trust GitLab for authentication. This process enables seamless and secure access to AWS resources directly from GitLab. The following image illustrates how Essent implements automated deployment from Gitlab CI/CD to AWS, using OIDC.

  • An Essent employee pushes a change to one of the GitLab repositories.
  • When receiving a change, merge or merge request, the pipeline will be triggered. This creates a job that will be executed by a GitLab runner instance holding a JSON Web Token (JWT). The JWT is signed by GitLab.
  • Gitlab issues an OIDC token
  • Gitlab CI/CD pipeline uses the OIDC token with AWS
  • AWS verifies the OIDC token against the GitLab OIDC provider.
  • AWS assumes the specified IAM role and provides temporary credentials.
  • If the IAM role has a trusted policy, which could allow a specific tag, Gitlab repository or branch, it will check if conditions are met.
  • The Gitlab CI/CD pipeline will make the changes, as defined by the employee.


Let's break it down, and give practical example:

  • IAM Role for OIDC: Apart from the standard configuration, it is possible to add additional conditions that will allow deployment from specified Gitlab tags, repositories and branches. Below there is a code snippet of an AWS IAM trust policy that allows deployment from a specific Gitlab project path.



  • Configure “.gitlab-ci.yml” file: A possible solution is to put the assume role logic in a bash script that can be pulled by other Gitlab CI/CD pipelines during deployment. Below there is an example of an prepare.sh script. This script can be put in any other Gitlab repository and be pulled in during deployment:




The image below shows a snippet of a .gitlab-ci.yml file, where the script shown above is pulled from a different Gitlab repository and executed. The only remaining configuration required is the following:

  • Setting variables: In the example, the AWS_ACCOUNT_ID and AWS_ROLE_ARN are set, to ensure deployment to the right environment and account
  • Id_tokens: Which refers to the OIDC token



SUMMARY

In summary, security is an important pilar for Essent. Even though there are several options for Gitlab CI/CD pipeline authentication, OIDC is preferred for GitLab and AWS due to its standardized approach and enhanced security and compliance benefits. These advantages collectively enhance the efficiency, security, and usability of authentication processes for Essent.



No comments have been posted yet.
Blog
To continue, please enter data in the marked fields.
To continue, please enter data in the marked fields.