How to run remote code as user with certificate from a worker node - ssl

I created a user in the Master.
First I created a key and certificate for him: dan.key and dan.crt
Then I created it inside Kubernetes:
kubectl config set-credentials dan \
--client-certificate=/tmp/dan.crt \
--client-key=/tmp/dan.key
This is the ~/.kube/config:
users:
- name: dan
user:
as-user-extra: {}
client-certificate: /tmp/dan.crt
client-key: /tmp/dan.key
I want to be able to run commands from a remote worker as the user I created.
I know how to do it with service account token:
kubectl --server=https://192.168.0.13:6443 --insecure-skip-tls-verify=true --token="<service_account_token>" get pods
I copied the certifiacte and the key to the remote worker and ran:
[workernode tmp]$ kubectl --server=https://192.168.0.13:6443 --client-certificate=/tmp/dan.crt --client-key=/tmp/dan.key get pods
Unable to connect to the server: x509: certificate signed by unknown authority
I followed this question:
kubectl unable to connect to server: x509: certificate signed by unknown authority
I tried like he wrote:
kubectl proxy --address 0.0.0.0 --accept-hosts '.*'
But I am still receiving:
Unable to connect to the server: x509: certificate signed by unknown authority

I copied the certifiacte and the key to the remote worker and ran:
[workernode tmp]$ kubectl --server=https://192.168.0.13:6443 --client-certificate=/tmp/dan.crt --client-key=/tmp/dan.key get pods
Unable to connect to the server: x509: certificate signed by unknown authority
You were missing the critical piece of data telling kubectl how to trust the https: part of that request, namely --certificate-authority=/path/to/kubernetes/ca.pem
You didn't encounter that error while using --token=... because of the --insecure-skip-tls-verify=true which you should definitely, definitely not do.
I tried like he wrote:
kubectl proxy --address 0.0.0.0 --accept-hosts '.*'
But I am still receiving:
You have followed the wrong piece of advice from whatever article you were reading; that --accept-hosts flag only controls the remote hostnames from which kubectl proxy will accept connections, and has zero to do with SSL anythings.

Related

Https for prometheus with self-signed ssl certificate

Trying to get up SSL for prometheus (started via docker). I generated key and crt myself using open ssl. Pair: key and crt works ok.
when I execute this command on my host:
openssl s_server -cert prometheus.crt -key prometheus.key
It's saying "ACCEPT"
Here is my Dockerfile for prometheus container:
https://pastebin.com/4wGtCGp6
When I build image and start it, it's saying:
level=error ts=2021-09-24T20:44:11.649Z caller=stdlib.go:105 component=web caller="http: TLS handshake error from 127.0.0.1:50458" msg="remote error: tls: bad certificate"
кричит постоянно
In the web.yml I configure SSL in a following way:
tls_server_config:
cert_file: /etc/prometheus/prometheus.crt
key_file: /etc/prometheus/prometheus.key
In the prometheus.yml I configure SSL in a following way:
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
scheme: https
tls_config:
ca_file: /etc/prometheus/prometheus.crt
cert_file: /etc/prometheus/prometheus.crt
key_file: /etc/prometheus/prometheus.key
What could be the reason of this error ?
If it's self-signed, you shouldn't need a CA file, so try deleting that line in the tls_config and restarting the container.
I know this is old, so apologies if it's bad to answer an old question. Feel free to delete.

Using kubectl behind SSL Interception

I am working with a Kubernetes cluster running in Azure Container Services. We use SSL Interception, which results in any kubectl command returning this error:
Unable to connect to the server: x509: certificate signed by unknown authority
I'm working on macOS 10.12.6
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.1", GitCommit:"f38e43b221d08850172a9a4ea785a86a3ffa3b3a", GitTreeState:"clean", BuildDate:"2017-10-11T23:27:35Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.9", GitCommit:"19fe91923d584c30bd6db5c5a21e9f0d5f742de8", GitTreeState:"clean", BuildDate:"2017-10-19T16:55:06Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Here is the verbose output for running kubectl version
$ kubectl version --v=10
I1128 10:27:28.721914 16346 loader.go:357] Config loaded from file /Users/foo/.kube/config
I1128 10:27:28.726719 16346 round_trippers.go:417] curl -k -v -XGET -H "Accept: application/json, */*" -H "User-Agent: kubectl/v1.8.1 (darwin/amd64) kubernetes/f38e43b" https://foo.westus2.cloudapp.azure.com/version
I1128 10:27:29.046962 16346 round_trippers.go:436] GET https://foo.westus2.cloudapp.azure.com/version in 320 milliseconds
I1128 10:27:29.046989 16346 round_trippers.go:442] Response Headers:
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.1", GitCommit:"f38e43b221d08850172a9a4ea785a86a3ffa3b3a", GitTreeState:"clean", BuildDate:"2017-10-11T23:27:35Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}
I1128 10:27:29.047291 16346 helpers.go:225] Connection error: Get https://foo.westus2.cloudapp.azure.com/version: x509: certificate signed by unknown authority
F1128 10:27:29.047310 16346 helpers.go:120] Unable to connect to the server: x509: certificate signed by unknown authority
Things I have tried:
Setting --insecure-skip-tls-verify=true results in another error Unable to connect to the server: EOF
Setting https_proxy to a proxy that is not under SSL Interception works correctly
Imported and trusted the ca from the apiserver
kubectl performs its own verification of the cluster's certificate outside of the OS' trusted certificate authorities, using the certificate authority defined in the certificate-authority-data field of the Kubeconfig file.
It is likely that the device performing the interception is a) replacing the cluster's certificate with its own, signed by a difference CA and b) unable to verify the cluster's certificate, which is signed by a different CA.
Depending on how the cluster is built, you may be able to issue certificates based on a pre-existing CA trusted by the interception device instead of a separate CA for the cluster. This is far beyond the scope of a StackOverflow answer; Kubernetes Up and Running and Kubernetes the Hard Way are good starting points, and you may need to read Kubernetes source code to get all the Key Usages of the certificates right.
It should be noted that SSL Interception is considered a bad practice (though it is widespread in some industries such as banking). TLS 1.3 is designed to prevent it entirely through the exclusive use of Perfect Forward Secrecy.

why kubelet communicate with apiserver by using TLS needs password?v1.3

I deployed apiserver using TLS on master node and it worked fine,my question appeared when I deploying the kubelet and tring to communicate with apiserver.
the kubelet conf as follows:
/opt/bin/kubelet \
--logtostderr=true \
--v=0 \
--api_servers=https://kube-master:6443 \
--address=0.0.0.0 \
--port=10250 \
--allow-privileged=false \
--tls-cert-file="/var/run/kubernetes/kubelet_client.crt" \
--tls-private-key-file="/var/run/kubernetes/kubelet_client.key"
--kubeconfig="/var/lib/kubelet/kubeconfig"
/var/lib/kubelet/kubeconfig is following:
apiVersion: v1
kind: Config
users:
- name: kubelet
user:
client-certificate: /var/run/kubernetes/kubelet_client.crt
client-key: /var/run/kubernetes/kubelet_client.key
clusters:
- name: kube-cluster
cluster:
certificate-authority: /var/run/kubernetes/ca.crt
contexts:
- context:
cluster: kube-cluster
user: kubelet
name: ctx-kube-system
current-context: ctx-kube-system
As I want to achieve the comunication using a two-way(both client and server)CA authentication and expect for a fluky reply,but apiserver ask me to provide my username and password which I have never used before,some command lines as following:
> kubectl version
> Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.2", GitCommit:"9bafa3400a77c14ee50782bb05f9efc5c91b3185", GitTreeState:"clean", BuildDate:"2016-07-17T18:30:39Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"}
> Please enter Username: kubelet
> Please enter Password: kubelet
> error: You must be logged in to the server (the server has asked for the client to provide credentials)
I tried all these on master minion.Could anyone please resolve this conundrum?Thanks in advance.
You have to enable client certificate authorization via the --client-ca-file flag on the apiserver.
From http://kubernetes.io/docs/admin/authentication/:
Client certificate authentication is enabled by passing the --client-ca-file=SOMEFILE option to apiserver. The referenced file must contain one or more certificates authorities to use to validate client certificates presented to the apiserver. If a client certificate is presented and verified, the common name of the subject is used as the user name for the request.
From http://kubernetes.io/docs/admin/kube-apiserver/:
--client-ca-file="": If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
--cloud-config="": The path to the cloud provider configuration file. Empty string for no configuration file.

docker pull gets me the error: "Download failed, retrying: x509: certificate signed by unknown authority"

so I am working behind a corporate Proxy that uses it's own, self-signed certificates.
What I did was editing ~/.curlc so that it is configured to use my proxy, as well as setting the environment variables http_proxy and https_proxy.
Then I installed the proxy's ca certificate by moving it into \etc\ssl\certs and creating the link to its hash via ln -s my_ca.pem `openssl x509 -hash -noout -in my_ca.pem`.0.
So now I can curl and wget and everything works fine.
Next I created the directory /etc/systemd/system/docker.service.d and created a new file in it called http-proxy.conf:
[Service]
Environment= "HTTP_PROXY=http://user:pass#proxy.corp.net:3128/" "HTTPS_PROXY=https://user:pass#proxy.corp.net:3128/"
After doing that docker search works as it should but I still cannot pull a container from the official registry.
systemctl status docker tells me: Download failed, retrying: x509: certificate signed by unknown authority
So I really don't know what else I can do for it to work. Maybe anybody on here has an idea?
EDIT
The full output of a docker pull call when running the docker daemon in debug mode:
DEBU[0092] Calling GET /v1.22/info
DEBU[0092] GET /v1.22/info
DEBU[0092] Calling POST /v1.22/images/create
DEBU[0092] POST /v1.22/images/create?fromImage=httpd%3Alatest
DEBU[0092] Trying to pull httpd from https://registry-1.docker.io v2
DEBU[0093] Increasing token expiration to: 0 seconds
DEBU[0094] Pulling ref from V2 registry: httpd:latest
DEBU[0094] pulling blob "sha256:7268d8f794c449e593d3a48f62e7e22b7c3a4b6e615caaf9494ec3cb2d48f503"
DEBU[0094] pulling blob "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
DEBU[0094] pulling blob "sha256:5d77cae53716e669a240114fc676b26cb052cb325078c869f884cab8a658be17"
ERRO[0095] Download failed, retrying: x509: certificate signed by unknown authority
ERRO[0095] Download failed, retrying: x509: certificate signed by unknown authority
ERRO[0095] Download failed, retrying: x509: certificate signed by unknown authority
...

Docker push to Artifactory fails - unable to ping resgistry endpoint

I am using Artifactory backed up by nginx as the proxy server. The nginx load balancer is configured with SSL certs from a trusted authority. I created a local docker repo and need to push images but get the following error:
unable to ping registry endpoint https://myArtifactory.com/v0/
v2 ping attempt failed with error: Get https://myArtifactory.com/v2/: x509: certificate signed by unknown authority
v1 ping attempt failed with error: Get https://myArtifactory.com/v1/_ping: x509: certificate signed by unknown authority
I am using the following command to push images
docker push myArtifactory.com/ubuntu
Fixed this bya dding the certificate to the docker client under /etc/docker/certs.d