Reputation: 177
I have a private docker registry in a google cloud k8s cluster that could be accessed only by IP.
What I've tried to do:
/etc/ssl/certs/registry-proxy-ca.pem
and run update-ca-certificates && systemctl restart docker
.I expect that client self-signed certificates will be approved from the k8s nodes when they tries to create pods and pull the images from the docker registry.
But I still have an error:
x509: certificate signed by unknown authority
Could anybody help me to understand what I did incorrectly? My script:
IP=10.3.240.100
LIFESPAN_DAYS=35600
CERTS_DIR=platform/cert-customizations/certs
CA_KEY=$CERTS_DIR/registry-proxy-ca.key
CA_PEM=$CERTS_DIR/registry-proxy-ca.pem
OPENSSL_CONFIG=$CERTS_DIR/openssl.cnf
REGISTRY_CERT_DIR=platform/registry-proxy/certs
REGISTRY_CERT_KEY=$REGISTRY_CERT_DIR/tls.key
REGISTRY_CERT=$REGISTRY_CERT_DIR/tls.crt
REGISTRY_CSR=$REGISTRY_CERT_DIR/registry-proxy.csr
REGISTRY_EXTFILE=$REGISTRY_CERT_DIR/extfile.cnf
echo subjectAltName = IP:$IP > $REGISTRY_EXTFILE
cat >>$OPENSSL_CONFIG <<EOL
[ req ]
default_bits = 2048
req_extensions = req_ext
x509_extensions = x509_ext
string_mask = utf8only
distinguished_name = subject
[ subject ]
# For simplicity, I will skip over the contents.
# ...
[ x509_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
[ req_ext ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
[ alternate_names ]
IP.1 = ${IP}
EOL
# Private key
openssl genrsa -out $CA_KEY 2048
# Public root CA
openssl req -subj "/CN=Nerdia Root CA" -x509 -new -nodes -key $CA_KEY -sha256 -days $LIFESPAN_DAYS -out $CA_PEM
# Create a cert for docker registry
openssl genrsa -out $REGISTRY_CERT_KEY 2048
openssl req -subj "/CN=${IP}" -config $OPENSSL_CONFIG -new -key $REGISTRY_CERT_KEY -out $REGISTRY_CSR
openssl x509 -req -in $REGISTRY_CSR -CA $CA_PEM -CAkey $CA_KEY -CAcreateserial -out $REGISTRY_CERT -days $LIFESPAN_DAYS -sha256 -extfile $REGISTRY_EXTFILE
Upvotes: 3
Views: 2375
Reputation: 9877
The issue in this particular question was related to the CRI
that the GKE
is using.
Citing slightly modified official documentation (part of it):
OS Node images Description Container-Optimized OS Container-Optimized OS with Containerd (cos_containerd) The cos_containerd
image uses Containerd as the container runtime directly integrated with Kubernetes. For more information, see Using Containerd imagesContainer-Optimized OS with Docker (cos) The cos
image uses the Docker container runtime-- Cloud.google.com: Kubernetes Engine: Docs: Concepts: Node images: Available Node images
The specific image:
gke-1199-gke1400-cos-85-13310-1209-12-v210407-c-pre
is using containerd
as CRI
and not Docker
(see the -c-
). Hence the: $ systemctl restart docker
did not give the expected result. The solution was to replace the docker
to containerd
in the systemctl restart ...
.
You can check which CRI
you are using by either running:
$ kubectl get nodes --output wide
Cloud Console
(Web UI)A side note!
Running Docker commands on Containerd nodes
While the Docker binary is currently available on Containerd nodes, we do not recommend using it after you migrate to Containerd. Docker does not manage the containers Kubernetes runs on Containerd nodes, thus you cannot use it to view or interact with running Kubernetes containers using Docker commands or the Docker API.
Warning: Docker cannot view or access containers or images managed by Kubernetes. Your applications should not interact with Docker directly. For general troubleshooting or debugging, use crictl instead.
-- Cloud.google.com: Kubernetes Engine: Docs: Concepts: Using containerd: Migrating
Additional resources:
Upvotes: 1