• IAM role
• Chart configuration
  • Registry
  • LFS, Artifacts, Uploads, Packages, Pseudonymizer
  • Backups

IAM roles for AWS

The default configuration for external object storage in the charts is to use access and secret keys. It is also possible to use IAM roles in combination with kube2iam or kiam.

IAM role

The IAM role will need read, write and list permissions on the S3 buckets. You can choose to have a role per bucket or combine them.

Chart configuration

IAM roles can be specified by adding annotations and changing the secrets, as specified below:

Registry

An IAM role can be specified via the annotations key:

--set registry.annotations."iam\.amazonaws\.com/role"=<role name>

When creating the registry-storage.yaml secret, omit the access and secret key:

s3:
  bucket: gitlab-registry
  v4auth: true
  region: us-east-1

Note: If you provide the keypair, IAM role will be ignored. See AWS documentation for more details.

LFS, Artifacts, Uploads, Packages, Pseudonymizer

For LFS, artifacts, uploads, packages and pseudonymizer an IAM role can be specified via the annotations key in the webservice and sidekiq configuration:

--set gitlab.sidekiq.annotations."iam\.amazonaws\.com/role"=<role name>
--set gitlab.webservice.annotations."iam\.amazonaws\.com/role"=<role name>

For the object-storage.yaml secret, omit the access and secret key. As GitLab’s Rails codebase uses Fog for S3 storage, the use_iam_profile key should be added for Fog to use the role:

provider: AWS
use_iam_profile: true
region: us-east-1

Backups

The Task Runner configuration allows for annotations to be set to upload backups to S3:

--set gitlab.task-runner.annotations."iam\.amazonaws\.com/role"=<role name>

The s3cmd.config secret is to be created without the access and secret keys:

[default]
bucket_location = us-east-1