Install registry CA cert in k8s runner when present
What does this MR do?
GitLab's registry can be configured with a self-signed certificate. This is common in development environments, but may also be done in corporate environments.
By default, self-signed certificates are treated as insecure, and rejected by docker-in-docker builds. This results in x509 errors when interacting with the registry.
To make for a more seamless Auto DevOps experience, and simplify local
development, we intorduce an optional configuration field registry.ca,
and add configuration to the GitLab-managed runner app to mount the
certificate (if present) at runtime at
/etc/docker/certs.d/$REGISTRY_HOST_PORT/ca.crt.
This way, docker-in-docker builds work out of the box.
Manual QA
1. The the default still works (no certificate present)
- attached a cluster
- installed Runner
- ran a CI job
- inspected the in-cluster state
-
✅ the job ran -
✅ registry data was not added to configmap, no certificate was mounted
2. It works with a valid certificate
-
added
registry.ca
to myconfig/gitlab.yml
registry: # ... ca: ../registry_host.crt
-
created a
kind
cluster and attached it to my local GitLab-
kind
has the following config:kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 networking: apiServerAddress: 0.0.0.0 kubeadmConfigPatchesJSON6902: - group: kubeadm.k8s.io version: v1beta2 kind: ClusterConfiguration patch: | - op: add path: /apiServer/certSANs/- value: gdk.test
-
listen_address
is set to a loopback alias IP ingdk.yml
, and the correspondinghostname
is assigned to this address in/etc/hosts
- my local registry is self-signed
-
-
installed GitLab runner
-
ran an Auto DevOps pipeline
Result: build
job succeeded
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides - [-] Database guides
- [-] Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. - [-] Tested in all supported browsers
- [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
- [-] Label as security and @ mention
@gitlab-com/gl-security/appsec
- [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- [-] Security reports checked/validated by a reviewer from the AppSec team