Deploy from Gitlab to AWS is a challenge because there is no dedicated method one can adopt to manage their stuff from Gitlab, therefore, it is important to know how you can securely deploy from Gitlab to AWS using IAM assume roles.
There are various ways companies run their CI/CD pipeline using various tools for each function whereas there is a growing demand to have all functionality from a single tool this way organization can work faster and have everything literally at one place.
A common approach or set of tools used for CI/CD:
- Versioning system like Github or Bitbucket to host code.
- Jenkins, CodeBuild, CodeDeploy etc., to build, test and deploy code.
- Artificatory, nexus etc., to store artifacts.
- Versioning system + CI/CD tools to build, test and deploy code + Artifact store + Resusablity of pipelines and artifacts across projects, inshort all-in-one.
There are also some downsides or let say gaps about using Gitlab one them is integration with public cloud platforms. Most of the organization run on the cloud and having integration with popular public cloud platforms make it easy for people to migrate and adapt their stacks on Gitlab. You don’t get plugins like on Jenkins here which means one has to develop their way around preparing a proper solution to integrate.
If you are deploying from Gitlab to AWS, the most common way to deploy is using an IAM user access key and secret access key to deploy, however, this approach is not the secure way and the reason is:
- Secrets leaked internally or externally could pose a risk of a larger blast radius because of the permissions a deployment user has is mostly admin like permissions.
- IAM user access key and secret key 🔐 can be accessed by anyone in the project.
When it comes to AWS, it is recommended to adopt its security best practices while connecting to AWS using a third-party tool. So when you are using Gitlab following things should be kept in mind to maintain a secured communication with AWS and its setup:
- Minimal permissions for the deployment user.
- Limited validity of the secrets.
- The secrets should be protected, yet easy to use.
Here is a sample architecture that covers all of the above-mentioned points ensuring properly secured setup on Gitlab…
On Gitlab, you need to adopt pipelines to work with time-based authentication IAM Assume Roles. Yes, you will require AWS access and secret key, without that it’s impossible to deploy from Gitlab access but hold your thought we would explain the whole setup below.
To elaborate above image here is list of things you can do:
- Create an intermediate/common AWS account that acts as a broker/divider between Gitlab and AWS Accounts
- The intermediate AWS account should only consist of IAM role and IAM users that Gitlab pipeline can use to access Main AWS accounts.
- Create IAM Users in Common account, give them rights only to assume a Service Role in the same account (Separate roles for prod and non-prod accounts is recommended)
- Create Deployment IAM assume role in destination accounts like “Account A” and allow it to be assumed using Service Role from “Common Account”.
Advantages of having above mentioned architecture:
- Gitlab will only use IAM user credentials of “Common Account” where there is nothing but IAM roles to assume.
- If credentials of the IAM user is leaked it would not lead to any security risk because those credentials will not give direct access to any AWS resources in other accounts, additionally would have limited access/ assume access only in “Common Account”.
- The probability of a hacker using those credentials to assume roles is unlikely because to assume one needs accounts id’s and role names to assume which can be masked as environment variables on Gitlab.
- Using separate “Service Roles” for production and non-production environment further limits the access to only specific accounts
- Only create “Deployment Roles” where required hence further restricts the access.
- If “Common Account” is compromised then you can create a new account or just recycle the IAM users credentials thus one does not have to do the same in all AWS accounts where they have workload running.
Cons of having above-mentioned architecture:
- Maintaining an additional AWS account.
- Recycling IAM user credentials of Common Account.
- Add functionality/code required to run Gitlab pipeline
This way you can achieve a properly secured and segregated CI/CD approach on Gitlab when deploying to AWS. IAM role-based authentication is a must to avoid store static secrets anywhere on Gitlab.
Here is a sample code with cloudfromation templates and a sample Gitlab CI/CD pipeline to deploy to AWS
Hope this article helped! Feel free to comment thoughts below, we would appreciate any comments to improve this architecture.
