I have a Microk8s cluster running gitea, harbor and droneci. Everything is hosted under *.dev.mydomain.com and there is a wildcard certificate for that. The certificate is signed using a private CA.
I'm trying to push the CA certificate to the Pods running the Drone CI builds such that they can push/pull from Gitea and Harbor while also being able to connect to external sources to (to fetch other docker images from dockerhub for example).
DroneCI and the drone runner are installed using Helm. I have tried the following in the values.yaml file for the runner:
DRONE_RUNNER_VOLUMES: "/sslcerts:/etc/ssl/certs"
This overwrites the /etc/ssl/certs/ folder in the runner pod. Any requests made from the pod to harbor or gitea work, any requests to anything else fail with error x509 certificate signed by unknown authority
I also tried
DRONE_RUNNER_VOLUMES: "/sslcerts/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt"
This returned the error mounting "/sslcerts/ca-certificates.crt" to rootfs at "/etc/ssl/certs/ca-certificates.crt" caused: mount through procfd: not a directory: unknown"
Any ideas on how to go about what I'm trying to do? Thanks!
As the runners are Alpine Linux based all you should have to do is to mount your certificates in the /usr/local/share/ca-certificates/ folder (not in a subfolder but right into that folder).
Alpine should then add all certificates from there to /etc/ssl/certs for you.
Related
I have microK8S cluster, and expose the API server at my domain.
The server.crt and server.key in /var/snap/microk8s/1079/certs need to be replaced with the ones that include my domain.
Otherwise, as expected, i get the error:
Unable to connect to the server: x509: certificate is valid for kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster, kubernetes.default.svc.cluster.local, not mydonaim.com
With the help of cert-manager I have produced certificates and replaced them, my system works well.
Problem: every time server is restarted, server.crt and server.key are generated again in
/var/snap/microk8s/1079/certs. My custom certs are deleted, making API server unreachable remotely.
How can I stop the system from doing that all the time?
Workaround?
Should I place my certificates elsewhere and edit config files like /var/snap/microk8s/1079/args/kube-controller-manager with the path to those certificates? Are those config files auto-replaced as well?
Cluster information:
Kubernetes version: 1.16.3
Cloud being used: Bare metal, single-node
cluster Installation method: Ubuntu Server with Snaps
Host OS: Ubuntu 18.04.3 LTS
It looks like there is an existing issue that describes copying and modifying the /var/snap/microk8s/current/certs/csr.conf.template to include any extra IP or DNS entries for the generated certificates
Please be aware of the proposed updates in https://discuss.kubernetes.io/t/services-and-ports/11263/6. The following command was required to run in my env:
sudo microk8s refresh-certs
I'm currently deploying a .net-core web-api to an docker container on rhel 7.1.
Everything works as expected, but from my application I need to call other services via https and those hosts use certificates signed by self-maintained root certificates.
In this constellation I get ssl-errors while calling this services (ssl-not valid) and therefore I need to install this root-certificate in the docker-container or somehow use the root-certificate in the .net-core application.
How can this be done? Is there a best practice to handle this situation? Will .net-core access the right keystore on the rhel-system?
Since .NET Core uses OpenSSL on linux, you need to set up your linux environment in the container so that OpenSSL will pick up the certificate.
This is done by (+ Dockerfile examples):
Copying the the certificate .crt file to a location that update-ca-certificates will scan for trusted certificates - e.g. /usr/local/share/ca-certificates/ or on RHEL /etc/pki/ca-trust/source/anchors/:
COPY myca.crt /usr/local/share/ca-certificates/
Invoking update-ca-certificates:
RUN update-ca-certificates
When I do docker pull from inside a container that uses /var/run/docker.sock to run docker (docker inside docker), I got this error:
FATA[0000] Error response from daemon: v1 ping attempt failed with error: Get https://registry.com:5000/v1/_ping: x509: certificate has expired or is not yet valid. If this private registry supports only HTTP or HTTPS with an unknown CA certificate, please add `--insecure-registry registry.com:5000` to the daemon's arguments. In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag; simply place the CA certificate at /etc/docker/certs.d/registry.com:5000/ca.crt
So I followed the instruction and added the ca.crt inside that directory and also added the insecure option to /etc/default/docker, but the error didn't go away.
I wonder where /var/run/docker.sock command look for the cert when I pull from inside the container. Especially when pulling works from outside (host) with the same config (ca.crt in the right folder and the insecure option is also added).
/var/run/docker.sock is not the thing that is looking for a cert. That is simply the socket that you use to communicate with dockerd. When you do a pull, you are asking the docker daemon to go talk to a registry.
Where did you get the ca.crt file? Is that really the signing certificate for your registry.com:5000 server's certificate? Did you put that in /et c/default/docker/registry.com:5000/ca.crt on the host where dockerd is running, or inside the container?
That ca.crt file belongs where the daemon is running. Double check that you have that correct file in the correct place on the host, and that should fix the issue.
Got it to work now, the solution is to restart the docker daemon inside the container. I actually tried it before but the docker service kept going down after restart, that made me think it was the docker service from the host.
The reason I could not restart docker service is /var/run/docker.pid existed which prevent docker from starting again. So I deleted that pid and docker restarted successfully.
I've tried to follow the following tutorial to setup our own private registry (v2) on an AWS Centos machine.
I've self signed a TLS certificate and placed it in /etc/docker/certs.d/MACHINE_STATIS_IP:5000/
When trying to login the registry (docker login MACHINE_IP:5000) or push a tagged repository (MACHINE_IP:5000/ubuntu:latest) i get the following error :
Error response from daemon: Get https://MACHINE_IP:5000/v1/users/: x509: cannot validate certificate for MACHINE_IP because it doesn't contain any IP SANs
Tried to search for an answer for 2 days, however I couldn't find any.
I've set the certificate CN (common name) to MACHINE_STATIC_IP:5000
When using a self signed TLS certificate docker daemon require you to add the certificate to it's known certificates.
Use the keytool command to grab the certificate :
keytool -printcert -sslserver ${NEXUS_DOMAIN}:${SSL_PORT} -rfc > ${NEXUS_DOMAIN}.crt
And copy it your client's machine SSL certificates directory (in my case - ubuntu):
sudo cp ${NEXUS_DOMAIN}.crt /usr/local/share/ca-certificates/${NEXUS_DOMAIN}.crt && sudo update-ca-certificates
Now reload docker daemon and you're good to go :
sudo systemctl restart docker
You can also use the following command to temporarily trust the certificate without adding it your system certificates.
docker --tlscert <the downloaded tls cert> pull <whatever you want to pull>
For https access I need to add a CA cert file to /usr/local/share/ca-certificates on my Ubuntu host machine.
Currently my Dockerfile RUN wget https... is failing since the certificate verification is failing.
How can Docker use the host machine CA cert? Or is there an existing enhancement opened to allow this?
I've used CA and SSL certs via a passthrough mount, but this looks like you're trying to do it in the Dockerfile.
So my suggestion would be - copy the CA cert to the image as part of the Dockerfile, and then proceed as normal. Or drop to http, or run wget --no-check-certificate if you're happy with that.
There are a few open bugs in this area:
https://github.com/docker/machine/issues/1799
https://github.com/docker/docker/issues/4372
https://github.com/docker/machine/issues/1435
https://github.com/deis/deis/issues/2230