Secrets Management with SOPS

Release notes

Problem to solve

Secure, flexible, file-based secrets management for GitLab users. As the Secrets Management direction page writes:

There are 3 classifications of secrets within the scope of Secret Management:

• static secrets
• dynamic secrets
• application secrets

In most cases, GitLab should not know about the application secrets and even many static secrets, but should be able to store them encrypted to be deployed to the target infrastructure. (It's even better, but in many cases not possible for the secret to never leave the target infrastructure.)

A concrete example

The company runs its services on top of Kubernetes and VM, uses Datadog as a managed service. Its services are composed of several microservices that rely on regular persistent storage (DB, object storage). All workloads are deployed by GitLab.

• Relying on the agent for Kubernetes, there is no need for dedicated access tokens to access the cluster, but there is still need to deliver the 3rd party passwords, tokens to the cluster.
• To access the VM, they need either
  • a Deploy Token deployed into the VM that allows the VM to reach GitLab or
  • a JWT - OpenId auth flow to access the VM from GitLab or
  • an access token stored and available in GitLab to access the target infrastructure
• To configure the applications to access Datadog, the database, etc they need their passwords or tokens deployed to the cluster.

Proposal

Integrate the open source SOPS tool into GitLab.

Vision

Various GitLab entities, like groups, projects, environments and users have their own age keys where the public key is available to group/project members or the given GitLab user, but the private key is restricted to GitLab.

GitLab CI having access to the private keys for the respective group/project:environment hierarchy can decrypt the respective SOPS encrypted files and make their content available as environment variables for GitLab CI.

deploy:
  stage: deploy
  environment:
    name: production
    variables: 
      - config.encrypted.json

A gitlab-cli integration makes it simple to encrypt files locally by running something like glab encrypt -p path/to/group/or/project -e my-environment --add-user config.json > config.encrypted.json

This command would retrieve the public key for the group/project/environment (environment being optional) and the user logged in with the CLI and encrypt the provided file with SOPS.

Note: If the user omits the --add-user flag, the file would be encrypted in a way that only GitLab would be able to decrypt it.
Note: The syntax would need to support several SOPS flags to allow encryption with 3rd party keys as well.

For audit, the encrypted file would contain a comment about the public keys used and a signature (of the header) by GitLab.

While most users likely don't need a UI to manage their secrets, there are situations where a UI would still be preferred. For this reason, GitLab could provide a UI to send in values to encrypt and store in git. The storage could happen either through the existing MR creation flow (needed for protected branches) or in a secondary repo attached to GitLab projects and groups (managed by GitLab), similarly to the wiki.

By standardizing on a single, open-source tool GitLab would enable its users and itself in the area. Users would be able to use the same tool for all their secrets. GitLab could use its APIs to encrypt/decrypt data when needed across systems as shown in the CI example above.

Tiering

There is potential for non-free tiers. For example:

• automatic key rotation
• audit reports on decryption usage
• etc

Iterations

I recommend starting with the environment.variables CI extension supported by a dedicated CI_GITLAB_AGE_KEY environment variable set by the user. GitLab would try to decrypt the provided file(s) with the given key and inject the decrypted values into the CI environment.

Intended users

• Cameron (Compliance Manager)
• Delaney (Development Team Lead)
• Sasha (Software Developer)
• Priyanka (Platform Engineer)
• Sidney (Systems Administrator)
• Sam (Security Analyst)
• Rachel (Release Manager)
• Alex (Security Operations Engineer)
• Allison (Application Ops)
• Ingrid (Infrastructure Operator)
• Dakota (Application Development Director)

Feature Usage Metrics

Usage could be measured by

• usage of environment.variables
• API to retrieve public keys
• GitLab CLI usage to encrypt variables

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.