Secrets
Overview
A secret is sensitive information that must be protected from unauthorized access or disclosure. Secrets are typically used by applications, services, or users to authenticate to or access other systems.
Examples of secrets include:
- Passwords
- API keys
- Access tokens
- Authentication tokens
- Encryption keys
- Other credentials or sensitive values used to access systems or services
TIP
A secret is any sensitive value that could be used to authenticate, gain access to a system, or otherwise compromise the security of an application or service if disclosed.
Secrets and GitLab
Secrets must not be stored in GitLab in plaintext or encrypted form. GitLab repositories, issues, merge requests, CI/CD variables, and other GitLab storage mechanisms are not approved locations for storing or transmitting secrets.
Do not include secrets in Jira or P1 Help Desk tickets. Secrets included in a Jira issue, Help Desk ticket, comment, or attachment are considered leaked. Do not use these systems to send or store passwords, tokens, API keys, or other secrets.
Do not commit secrets to source code or store them in:
- Git repositories
- Configuration files
- Kubernetes manifests
- GitLab CI/CD configuration
- GitLab issues or comments
- Merge requests
- Jira or P1 Help Desk tickets
- Other GitLab-hosted content
If a secret is accidentally committed to GitLab, do not assume that deleting the file, commit, or branch makes the secret secure. The secret should be considered exposed and must be handled according to P1 security procedures, including replacement or rotation as appropriate.
At P1, Secret Operations (SOPS) encrypts secrets within mission-bootstrap, backed by Amazon KMS. This provides the approved mechanism for securely storing encrypted secrets used by the platform.
INFO
Currently, product teams cannot encrypt Kubernetes secrets themselves. An MDO engineer will encrypt Kubernetes secrets.
Encryption process
WARNING
Do not send or store secrets in GitLab. Secrets stored anywhere in GitLab are not considered secure and are against P1 policy.
Identify the secrets your application needs.
During pipeline setup, a DevOps engineer will work with your product team to identify any Kubernetes secrets that your application needs at runtime.Use the standard process for RDS credentials.
For RDS PostgreSQL or MySQL credentials, a DevOps engineer will generate and encrypt the required credentials.Contact your DevOps engineer for other secrets.
If your application needs other secrets at runtime, contact the DevOps engineer assigned to your epic. If no DevOps engineer is assigned, submit a helpdesk ticket.Send the secrets through DoW SAFE.
Send the credentials that need encryption through DoW SAFE. Do not send secrets through GitLab, email, chat, or other unapproved methods. DoW SAFE is the only approved application for sending Kubernetes secrets to an MDO engineer for encryption.Have an MDO engineer encrypt the secrets.
An MDO engineer will encrypt the Kubernetes secrets using the approved encryption process. Product teams cannot encrypt Kubernetes secrets themselves at this time.Add the encrypted secret reference to your Kubernetes manifests.
After the MDO engineer encrypts the secrets, you must add a reference to the encrypted secrets in your application's Kubernetes manifests. This makes the secrets available to your application at runtime.- If your team is comfortable modifying the Kubernetes manifests, you can make the changes yourself.
- You can also ask the DevOps engineer assigned to your epic for help. If no DevOps engineer is assigned, submit a General Support request through the P1 Help Desk .
Additional comments
The following is an example of a reference to a Kubernetes Secret in an application's deployment.yaml manifest:
-secretRef:
name: app-db-credentialsINFO
Consult with a DevOps engineer to confirm the appropriate value for the name field.