docker desktop on mac is getting error:
Unable to connect to the server: x509: certificate signed by unknown authority
The following answers didn't helped much:
My system details:
Operating system: macOS Big Sur Version 11.6
Docker desktop version: v20.10.12
Kubernetes version: v1.22.5
When I do:
kubectl get pods
I get the below error:
Unable to connect to the server: x509: certificate signed by unknown authority
Posting the answer from comments
As appeared after additional questions and answers, there was a previous installation of rancher cluster which left its traces: certificate and context in ~/.kube/config.
The solution in this case for local development/testing is to delete entirely ~/.kube folder with configs and init the cluster from the scratch.
If you are using a corporate laptop, and everything you do goes through a proxy, you will get this message. Hence, when docker desktop tries to connect to the server defined in ~/.kube/config, it will try to go through the proxy and you will need the cert issued by the company. Long story short, you are getting blocked by the the company... To fix, you can add the no proxy props, adding what ever value server: internal.docker defined in~/.kube/config . Meaning, if I am connecting to docker cluster which runs locally in my laptop, do not direct my traffic through proxy.
When doing docker info, after setting no proxy, you should see something like this.
docker info | grep -i proxy
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal,localhost,127.0.0.1,.local,.us.example.com,.examplecorp.com,.examplevcn.com,kubernetes.docker.internal
hubproxy.docker.internal:5000
Related
how to add a trusted CA for local Consul docker container?
So I have a consul running as a docker container and I am able to access it using chrome at localhost:8500 after exposing the ports, as expected. But due to company setting there is a security CA being added that chrome trusts, since it is added to MacOS keychain, but consul does not seems to trust when I try to use golang library to connect to consul
x509: “Menlo Security Intermediate CA” certificate is not trusted"
I get a certificate is not trusted error. I am able to export the CA to a RootCA.cer file from the keychain but how do I configure consul image to trust this CA file?
https://iotech.force.com/edgexpert/s/article/secure-consul-tls
I see articles like this
ca_file is used to check the authenticity of the client and server connections
cert_file is provided to clients and server to verify the agent's authenticity
key_file is used with the certificate to verify the agent's authenticity
but for me, the .cer export file will be used as cert_file?
how should I do it in docker compose?
consul:
image: dockerproxy.comp.com/consul:latest
ports:
- "9500:9500"
I am using Kind with docker-compose.
In my docker-compose file, I have the following line
extra_hosts:
- "host.docker.internal:host-gateway"
This allows me to connect to Kind, which is running in localhost.
However, Kind only issue certificate to localhost, not to host.docker.internal.
I know that kubectl can ignore the certificate, but how to do the same with the Go client?
clientset := kubernetes.NewForConfigOrDie(ctrl.GetConfigOrDie())
The error
app-1 | panic: Get "https://host.docker.internal:33345/apis/apps/v1/namespaces/argo/deployments": x509: certificate is valid for kind-control-plane, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, localhost, not host.docker.internal
When working behind a corporate proxy (automatically activated in Windows) by Cisco AnyConnect(v4.7.03052) VPN, I'm unable to pull any docker image either from our docker nexus registry or the official registry.
Funny enough, if I set the proxy settings in the config.json and pass the proxy as build-arg my containers are able to build(from previously pulled images) and talk to the exterior.
Only the docker engine is unable to access the internet through the proxy.
I've already tried the following:
Set the HTTP_PROXY/HTTPS_PROXY as environments variables
Set the proxy settings in the Docker Desktop proxy section - Docker doc
Set the resources network IP to the non-secured Cisco AnyConnect routes IPv4
No firewall rules seems to block the outbound request from the docker engine service.
Edit the deamon.json used by the docker service to register the mirror registries.
Stackoverflow answers not working in this case: docker-win10; docker on windows; docker image proxy
Platform info:
Win 10 - Build 19401
Docker Desktop 4.4.4(73704)
Docker Engine 20.12.12 (Linux container on Hyper-V)
Cisco AnyConnect v4.7.03052
Error message on docker pull:
λ docker pull traefik:2.0
Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Based on the similar stackoverflow issue briefly executing the command below had it working for a short time:
cd "C:\Program Files\Docker\Docker"
./DockerCli.exe -SwitchDaemon
This was a regression that slipped in the 4.4.4 see github issue.
It seems to have been resolved in the v4.5.0
When I'm trying to get the Docker integration of IntelliJ (Ultimate 2018.3.3) working together with local running Docker Desktop (Version 2.0.0.3 (31259)), I'm getting the following error:
Cannot connect: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information: localhost:127.0.0.1:2375
caused by: java.net.ConnectException: Connection refused: no further information
I found the following question: IntelliJ cannot connect to protected tcp Docker socket
But this solution leads to this error:
Cannot connect: com.github.dockerjava.api.exception.DockerClientException: Enabled TLS verification (DOCKER_TLS_VERIFY=1) but certificate path (DOCKER_CERT_PATH) is not defined.
I searched for the cert path of Docker Desktop but found nothing yet because the new Hyper-V solution of Docker Desktop doesn't run docker-machine native any more.
The solution is to enable exposing the Docker deamon on tcp:localhost:2375 without TLS.
This option can be found in general settings of Docker Desktop (Version 2.0.0.3).
Setting / General / Expose daemon on tcp://localhost:2375 without TLS
I have an etcd cluster using TLS for security. I want other machines to use etcd proxy, so the localhost clients don't need to use TLS. Proxy is configured like this:
[Service]
Environment="ETCD_PROXY=on"
Environment="ETCD_INITIAL_CLUSTER=etcd1=https://master1.example.com:2380,etcd2=https://master2.example.com:2380"
Environment="ETCD_PEER_TRUSTED_CA_FILE=/etc/kubernetes/ssl/ca.pem"
Environment="ETCD_PEER_CERT_FILE=/etc/kubernetes/ssl/worker.pem"
Environment="ETCD_PEER_KEY_FILE=/etc/kubernetes/ssl/worker-key.pem"
Environment="ETCD_TRUSTED_CA_FILE=/etc/kubernetes/ssl/ca.pem"
And it works, as far as the first connection goes. But the etcd client does an initial query to discover the full list of servers, and then it performs its real query against one of the servers in that list:
$ etcdctl --debug ls
start to sync cluster using endpoints(http://127.0.0.1:4001,http://127.0.0.1:2379)
cURL Command: curl -X GET http://127.0.0.1:4001/v2/members
got endpoints(https://1.1.1.1:2379,https://1.1.1.2:2379) after sync
Cluster-Endpoints: https://1.1.1.1:2379, https://1.1.1.2:2379
cURL Command: curl -X GET https://1.1.1.1:2379/v2/keys/?quorum=false&recursive=false&sorted=false
cURL Command: curl -X GET https://1.1.1.2:2379/v2/keys/?quorum=false&recursive=false&sorted=false
Error: client: etcd cluster is unavailable or misconfigured
error #0: x509: certificate signed by unknown authority
error #1: x509: certificate signed by unknown authority
If I change the etcd masters to --advertise-client-urls=http://localhost:2379, then the proxy will connect to itself and get into an infinite loop. And the proxy doesn't modify the traffic between the client and the master, so it doesn't rewrite the advertised client URLs.
I must not be understanding something, because the etcd proxy seems useless.
Turns out that most etcd clients (locksmith, flanneld, etc.) will work just fine with a proxy in this mode. It's only etcdctl that behaves differently. Because I was testing with etcdctl, I thought the proxy config wasn't working at all.
If etcdctl is run with --skip-sync, then it will communicate through the proxy rather than retrieving the list of public endpoints.
etcdctl cluster-health ignores --skip-sync and always touches the public etcd endpoints. It will never work with a proxy.
With option --endpoints "https://{YOUR_ETCD_ADVERTISE_CILENT_URL}:2379".
Because you configured TLS for etcd, you should add options --ca-file, --cert-file, --key-file.