Secrets Management for gitlab-org/gitlab

This documentation aims to detail the methodologies and practices adopted by the GitLab project concerning the storage and management of secrets in a production environment. The techniques illustrated here will focus on code examples and workflows that ensure the security and integrity of sensitive information.

Overview

Secrets management in GitLab ensures that sensitive information—like API keys, access tokens, and certificates—are securely stored and accessed during build and runtime. This section is meant for experienced developers familiar with GitLab and containerized applications.

Dockerfile: Secrets Management via Build Arguments and Environment Variables

In GitLab, the Dockerfile plays a crucial role in how secrets are handled during the image-building phase. The use of build arguments and environment variables is prominently featured, ensuring sensitive information isn’t hardcoded but instead passed at build time.

Example Dockerfile Snippet

ARG BUILD_OS=debian
ARG RUBY_VERSION=3.2.4

FROM registry.gitlab.com/gitlab-org/gitlab-build-images/${BUILD_OS}-${OS_VERSION}-ruby-${RUBY_VERSION}:git-${GIT_VERSION}-lfs-${LFS_VERSION}-chrome-${CHROME_VERSION}-docker-${DOCKER_VERSION}-gcloud-${GCLOUD_VERSION}-kubectl-${KUBECTL_VERSION}-helm-${HELM_VERSION} AS foss

In this snippet, various build arguments like BUILD_OS and RUBY_VERSION are defined, and these can be passed during the build process but are not part of the final image. This keeps the image cleaner and more secure.

Installing Secrets Management Tools

GitLab utilizes tools like the 1Password CLI for enhanced secrets management. This example shows how to install the 1Password CLI in the Docker container.

# Install 1Password CLI
RUN wget -P /tmp/ https://downloads.1password.com/linux/debian/$(dpkg --print-architecture)/stable/1password-cli-$(dpkg --print-architecture)-latest.deb
RUN dpkg -i /tmp/1password-cli-$(dpkg --print-architecture)-latest.deb
RUN op --version

By employing the 1Password CLI, sensitive information can be retrieved on-the-fly, reducing the need to embed such data directly within the application code or configuration files.

Managing Certificates

For applications that require certificates to establish secure connections, GitLab incorporates custom root certificates securely during the image build.

# Install root certificate
RUN mkdir -p /usr/share/ca-certificates/gitlab
ADD ./qa/tls_certificates/authority/ca.crt /usr/share/ca-certificates/gitlab/
RUN echo 'gitlab/ca.crt' >> /etc/ca-certificates.conf
RUN chmod -R 644 /usr/share/ca-certificates/gitlab && update-ca-certificates

This methodology allows for further protection of connection endpoints by ensuring the application trusts the appropriate certificate authorities without exposing sensitive data in the repository.

Environment Variables at Runtime

In addition to build time strategies, managing secrets via environment variables at runtime is vital in production deployments. Developers can set sensitive variables in the deployment environment, keeping them out of the source code.

Setting Environment Variables

When deploying GitLab, secrets can be passed as environment variables, typically in the docker-compose.yml file:

app:
  image: gitlab/gitlab-ce:latest
  environment:
    - GITLAB_SECRETS_DB_KEY_BASE=${GITLAB_SECRETS_DB_KEY_BASE}
    - GITLAB_SECRETS_SECRET_KEY_BASE=${GITLAB_SECRETS_SECRET_KEY_BASE}

In this example, the database and secret keys are set up as environment variables, making it straightforward to manage these secrets without hardcoding them into the application or image.

Conclusion

Secrets management is a critical element of deploying secure applications in production. Through the effective use of Docker build arguments, external secret management tools like 1Password, and environment variables, GitLab provides robust methodologies for managing sensitive data.

This approach ensures that developers can maintain a high level of security throughout the software lifecycle while minimizing the risk of exposing sensitive information.

Source: Documentation derived from the GitLab project structure and practices as observed in the Dockerfile and docker-compose.yml files.