6. Access management cheat sheet

Relations between GitLab and AWS entities

Assuming that:

• GitLab group = AWS S3 bucket + IAM user group + IAM policy for this bucket
• User can access the client's projects (repositories) = User is present in the IAM user group
• GitLab project (repository) = A folder in the bucket

Note that IAM user group IS NOT a team of developers because GitLab (at least CE) does not have such entity and ACL for it. GitLab groups incorporate a set of projects from the same client. Thus, Grant access to the GitLab group means Add IAM User to the IAM group.

This schema may not match your needs. Create and document your own way to manage permissions if needed.

Changing permissions

Creating a new GitLab group (or a subgroup)?

1. Add respective devs to this GitLab group.
2. Create S3 bucket for this GitLab group.
3. Create a new IAM user group.
4. Create a new IAM policy for this bucket.
5. Attach this new IAM policy to the respective IAM group.
6. Add IAM users to this new IAM group.
7. Attach this new IAM policy to a special group for the CI/CD pipeline that builds DB images.
8. Add a new trigger to the AWS Lambda.
9. Add a Database Image Builder user to this new GitLab (sub)group.

Creating a new GitLab project?

Nothing to configure.

Creating a new GitLab user?

1. Add this GitLab user to the respective GitLab groups.
2. Create a new IAM user.
3. Add this IAM user to the respective IAM group(s).

Adding existing user to a group or removing them?

Add or remove users from the IAM user groups when you do the same in GitLab. And vice versa.

Creating a new team in your company?

There are no teams in GitLab. Just ensure that users are added to the proper GitLab groups and IAM user groups.