Kaniko mit Custom CA Certificates
Damit Kaniko mit einer eigenen Registry verwendet werden kann, die TLS Zertifikate von einer eigenen Certificate Authority (CA) verwendet, wird ein eigenes Kaniko Container-Image benötigt. Wenn darin die passenden Zertifikate enthalten sind, kann Kaniko auf die Registry ohne Probleme zugreifen.
Dieses Beispiel baut auf dem vorherigen Beitrag auf und verwendet daher schon ein spezielles Kaniko Image für ARM Maschinen.
Im Prinzip ist das Vorgehen einfach:
Das CA Zertifikat muss den vertrauenswürdigen Zertifikaten im Kaniko Image hinzugefügt werden.
Kaniko erwartet die Zertifikate in /kaniko/ssl/certs/ca-certificates.crt, sodass hier ein CA Zertifikat problemlos ergänzt werden kann.
Je nachdem, welche Quelle für das Zertifikat dient, muss es in den Build-Container kopiert werden bzw. aus der Umgebung konfiguriert werden.
Im Beispiel wird die Kubernetes CA verwendet, so dass sich das CA Zertifikat in /var/run/secrets/kubernetes.io/serviceaccount/ca.crt befindet.
Das für den Build erforderliche Dockerfile wird als Kubernetes-ConfigMap bereitgestellt.
So sieht der Kubernetes Build-Job als YAML dann aus:
---
kind: ConfigMap
apiVersion: v1
metadata:
name: kaniko-ca-dockerfile
data:
Dockerfile: |
FROM registry.docker-registry:5000/kaniko/executor as origin
FROM alpine as prepare
COPY --from=origin /kaniko/ssl/certs/ca-certificates.crt ca-certificates.crt
COPY serviceaccount/ca.crt ca.crt
RUN echo "-----BEGIN CERTIFICATE-----" >> ca-add.crt; cat ca.crt >> ca-add.crt; echo "-----END CERTIFICATE-----" >> ca-add.crt; cat ca-add.crt >> ca-certificates.crt
FROM registry.docker-registry:5000/kaniko/executor
COPY --from=prepare ca-certificates.crt /kaniko/ssl/certs/ca-certificates.crt
---
apiVersion: batch/v1
kind: Job
metadata:
name: kaniko-build
labels:
run: dind
name: dind
spec:
ttlSecondsAfterFinished: 10
template:
spec:
containers:
-
image: 'docker:dind'
name: dind
args:
- '--insecure-registry=registry.docker-registry:5000'
workingDir: /repo
securityContext:
privileged: true
volumeMounts:
-
name: cache-volume
mountPath: /tmp
-
name: container-volume
mountPath: /var/lib/docker
-
image: 'docker:dind'
name: docker
args:
- /bin/sh
- '-c'
- 'cp -r /var/run/secrets/kubernetes.io/serviceaccount/ .; docker build -f config/Dockerfile -t registry.docker-registry:5000/kaniko/ca-executor .; docker images; docker push registry.docker-registry:5000/kaniko/ca-executor; echo "completed"'
workingDir: /tmp
env:
-
name: DOCKER_HOST
value: 'tcp://localhost:2375'
volumeMounts:
-
name: cache-volume
mountPath: /tmp
-
name: dockerfile
readOnly: false
mountPath: /tmp/config
volumes:
-
name: container-volume
emptyDir: {}
-
name: cache-volume
emptyDir: {}
-
name: dockerfile
configMap:
name: kaniko-ca-dockerfile
restartPolicy: NeverDer Build erfolgt dann dadurch, dass der Job in Kubernetes angelegt wird. Nach erfolgreichem Build kann der Job und die ConfigMap wieder entfernt werden.
$ kubectl apply -f build.yaml
configmap/kaniko-ca-dockerfile created
job.batch/kaniko-build created
# warten oder Logs verfolgen...
$ kubectl delete -f build.yaml
configmap "kaniko-ca-dockerfile" deleted
job.batch "kaniko-build" deletedDas so gebaute Image ist nun in der Registry verfügbar und kann für Kaniko-Builds verwendet werden.
Zu den Themen Kubernetes, Docker und Cloud Architektur bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:
Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.