Using the Shared-Secrets Job
- Tier: Free, Premium, Ultimate
- Offering: GitLab Self-Managed
The shared-secrets
job is responsible for provisioning a variety of secrets
used across the installation, unless otherwise manually specified. This includes:
- Initial root password
- Self-signed TLS certificates for all public services: GitLab, MinIO, and Registry
- Registry authentication certificates
- MinIO, Registry, GitLab Shell, and Gitaly secrets
- Redis and PostgreSQL passwords
- SSH host keys
- GitLab Rails secret for encrypted credentials
Installation command line options
The table below contains all the possible configurations that can be supplied to
the helm install
command using the --set
flag:
Parameter | Default | Description |
---|---|---|
enabled | true | See Below |
env | production | Rails environment |
podLabels | Supplemental Pod labels. Will not be used for selectors. | |
annotations | Supplemental Pod annotations. | |
image.pullPolicy | Always | DEPRECATED: Use global.kubectl.image.pullPolicy instead. |
image.pullSecrets | DEPRECATED: Use global.kubectl.image.pullSecrets instead. | |
image.repository | registry.gitlab.com/gitlab-org/build/cng/kubectl | DEPRECATED: Use global.kubectl.image.repository instead. |
image.tag | 1f8690f03f7aeef27e727396927ab3cc96ac89e7 | DEPRECATED: Use global.kubectl.image.tag instead. |
priorityClassName | Priority class assigned to pods | |
rbac.create | true | Create RBAC roles and bindings |
resources | resource requests, limits | |
securityContext.fsGroup | 65534 | User ID to mount filesystems as |
securityContext.runAsUser | 65534 | User ID to run the container as |
selfsign.caSubject | GitLab Helm Chart | selfsign CA Subject |
selfsign.image.repository | registry.gitlab.com/gitlab-org/build/cnf/cfssl-self-sign | selfsign image repository |
selfsign.image.pullSecrets | Secrets for the image repository | |
selfsign.image.tag | selfsign image tag | |
selfsign.keyAlgorithm | rsa | selfsign cert key algorithm |
selfsign.keySize | 4096 | selfsign cert key size |
serviceAccount.enabled | true | Define serviceAccountName on job(s) |
serviceAccount.create | true | Create ServiceAccount |
serviceAccount.name | RELEASE_NAME-shared-secrets | Service account name to specify on job(s) (and on the serviceAccount itself if serviceAccount.create=true ) |
tolerations | [] | Toleration labels for pod assignment |
Job configuration examples
tolerations
tolerations
allow you schedule pods on tainted worker nodes
Below is an example use of tolerations
:
tolerations:
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoSchedule"
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoExecute"
Disable functionality
Some users may wish to explicitly disable the functionality provided by this job.
To do this, we have provided the enabled
flag as a boolean, defaulting to true
.
To disable the job, pass --set shared-secrets.enabled=false
, or pass the following
in a YAML via the -f
flag to helm
:
shared-secrets:
enabled: false
If you disable this job, you must manually create all secrets, and provide all necessary secret content. See installation/secrets for further details.
Docs
Edit this page to fix an error or add an improvement in a merge request.
Create an issue to suggest an improvement to this page.
Product
Create an issue if there's something you don't like about this feature.
Propose functionality by submitting a feature request.
Feature availability and product trials
View pricing to see all GitLab tiers and features, or to upgrade.
Try GitLab for free with access to all features for 30 days.
Get help
If you didn't find what you were looking for, search the docs.
If you want help with something specific and could use community support, post on the GitLab forum.
For problems setting up or using this feature (depending on your GitLab subscription).
Request support