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
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"
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
I have a laravel application running which tries to upload files to a local minio server which runs on https on port 9001.
This happens on a server with a public domain name we shall call foo.bar.com.
In the host machine (outside my docker containers) if I do curl -k https://foo.bar.com:9001 or curl -k https://0.0.0.0:9001 it works, but if I try to run these commands inside my laravel container I get curl: (7) Failed to connect to 0.0.0.0 port 9001: Connection refused.
In the container I can do connect to my minio server by using the minio containers name since they are on the same network curl -k https://pan.api.minio:9001.
I wanted to use this but then running migrations in laravel fails with Error executing "PutObject" on "https://pan.api.minio:9001/pan-local/ab7d6e69-5e13-4582-8855-669dcb935591/OVVzTEZiOGhSR3J1MkVHSmlIa3VoSXNsTFdJVnNWWlNCb0U2dnlsWm13dmNGUjRvWlVIVVJRTWxqak1reVhMUm1hbmV0LTItMQ%3D%3D"; AWS HTTP error: cURL error 60: SSL: no alternative certificate subject name matches target host name 'pan.api.minio' (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)
I just want to upload files to my minio server from within my laravel container, but why can't I connect to it by doing foo.bar.com:9001 like I can outside of my docker containers?
I'm trying to connect to remote docker host through ssh tunnel. I have forwarded the 2375 port and I'm trying to connect to it by specifying DOCKER_HOST.
$ DOCKER_API_VERSION=1.24 DOCKER_HOST=localhost:2375 docker ps
error during connect: Get https://localhost:2375/v1.24/containers/json: http: server gave HTTP response to HTTPS client
This have worked before, but I can't make it work again, because my docker client keep giving me back this error. I can't make it ignore the https/http stuff. The connection is OK, i can curl the endpoints just fine, its just that docker client is doing something and then preventing itself from connecting and I don't know how to make it ignore the https.
I have finally figured out why I was getting this error. I was positive DOCKER_TLS_VERIFY was not set, but it was. So if anyone get this error, make sure the env variable is undefined or that the value is empty.
using
$ DOCKER_API_VERSION=1.24 DOCKER_HOST=localhost:2375 DOCKER_TLS_VERIFY= docker ps
did work as expected.
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.