Allow passing of generic secrets from GitLab to a Workspace
Problem Statement
When a create is workspace from a project, certain secrets might be required for the correct working of the project e.g. sentry access key to log errors in development cycle or AWS api access key to access some AWS resource during development.
We need a way to inject secrets into a workspace.
Possible Solutions
Possible Solution 1 - Use GitLab as secrets store and sync secrets to Kubernetes
- Allow users to define secrets at a project. user and workspace level.
- When defined at a project level, any user who can create a workspace from the project, will have those secrets injected into the workspace.
- When defined at a user level, all workspaces created by a user would have those secrets injected into the workspace.
- When defined at a workspace level, only the said workspace would have those secrets injected into the workspace.
- If there is a namespace clash between project level secrets and user level secrets, user level secrets will take precedence.
- If there is a namespace clash between user level secrets and workspace level secrets, workspace level secrets will take precedence.
- Defining workspace level secrets allows us to enforce certain secrets that we'd like to inject into a workspace.
- Define a new module in GA4K which syncs secrets from GitLab into Kubernetes as Secrets.
- Reference - https://secrets-store-csi-driver.sigs.k8s.io/concepts.html and https://github.com/aws/secrets-store-csi-driver-provider-aws
- This module will look for
secretproviderclasses.secrets-store.csi.x-k8s.io
resources and based on their definition, it will sync the data from GitLab as Kubernetes Secrets. If we want to refrain from using a CRD, we can use watch over a ConfigMap/Secret with particular label which defines what secrets from GitLab are needed for a given workspace.
- As part of Remote Development, when create a workspace, along with Deployment and Service Kubernetes resources, create a
SecretProviderClass
Kubernetes resource(or the required ConfigMap/Secret resource). - This would also allow for secret auto rotation in GitLab with sync in the Kubernetes secrets and Kubernetes Pods mounting the said Secret.
- The secrets will be stored in the database encrypted, as they are right now for CI/CD secrets.
Possible Solution 2 - Explore how Runner is injecting CI secrets for jobs deployed in Kubernetes
- ...?
Possible Solution 3 - ...?
Edited by Vishal Tak