Use .kube/config Client certs in curl

guettli

6/21/23, 5:23 PM

If you use kubectl get pod foo -v10 you see a curl line, but this does not work.

Example:

guettli@p15:~$ curl -k -v -XGET  -H "Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json" -H "User-Agent: kubectl/v1.23.4 (linux/amd64) kubernetes/e6c093d" 'https://127.0.0.1:44529/api/v1/namespaces/default/pods/busybox' 

*   Trying 127.0.0.1:44529...
* Connected to 127.0.0.1 (127.0.0.1) port 44529 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=kube-apiserver
*  start date: Feb  2 10:34:41 2022 GMT
*  expire date: Feb  2 10:34:41 2023 GMT
*  issuer: CN=kubernetes
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55ef6413b5e0)
> GET /api/v1/namespaces/default/pods/busybox HTTP/2
> Host: 127.0.0.1:44529
> accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json
> user-agent: kubectl/v1.23.4 (linux/amd64) kubernetes/e6c093d
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 403 
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< x-kubernetes-pf-flowschema-uid: d45b0ee7-7e06-463e-b8d1-6ab74852b967
< x-kubernetes-pf-prioritylevel-uid: 3be84978-2771-4afe-972d-50dec7f8b951
< content-length: 289
< date: Mon, 21 Feb 2022 17:20:21 GMT
< 

{"kind":"Status","apiVersion":"v1","metadata":{},
 "status":"Failure",
 "message":"pods \"busybox\" is forbidden: User \"system:anonymous\" cannot get resource \"pods\" in API group \"\" in the namespace \"default\"",
 "reason":"Forbidden",
 "details":{"name":"busybox","kind":"pods"},"code":403}

* Connection #0 to host 127.0.0.1 left intact

How can I use the client cert which in in .kube/config?

I use kind 0.11.1

0 + 0

curl

kubernetes

kind

mdaniel

6/21/23, 5:36 PM

Well, what have you tried so far, other than just magically expecting `curl` to parse a kubeconfig yaml file? Also, in the spirit of an "X/Y problem," this sure does sound like you're wanting to reimplement `kubectl` using a lot of bash for some reason

Score:1

Server

guettli

6/21/23, 7:37 PM

I found this solution:

cat .kube/config | yq .clusters[0].cluster.certificate-authority-data | base64 -d - > .kube/ca.pem

cat .kube/config | yq .users[0].user.client-certificate-data | base64 -d - > .kube/user.pem

cat .kube/config | yq .users[0].user.client-key-data | base64 -d - > .kube/user-key.pem

curl --cert .kube/user.pem --key .kube/user-key.pem --cacert .kube/ca.pem \
  -v -XGET  -H "Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json" \
  -H "User-Agent: kubectl/v1.23.4 (linux/amd64) kubernetes/e6c093d" \
 'https://127.0.0.1:44529/api/v1/namespaces/default/pods/busybox'

0 + 0

Score:0

Server

Sergey Fedyanov

9/5/23, 10:59 PM

I've done some research. My working solution is below:

Quotes are required because of dashes in tag names:

cat ~/.kube/config | yq -r '.clusters[0].cluster."certificate-authority-data"' | base64 -d - > ~/.kube/ca.pem 
cat ~/.kube/config | yq -r '.users[0].user."client-certificate-data"' | base64 -d - > ~/.kube/user.pem
cat ~/.kube/config | yq -r '.users[0].user."client-key-data"' | base64 -d - > ~/.kube/user-key.pem

One more useful variable:

SERVER_URL=$(cat ~/.kube/config | yq -r .clusters[0].cluster.server)

Curl example:

curl --cacert ~/.kube/ca.pem --cert ~/.kube/user.pem --key ~/.kube/user-key.pem -X GET  ${SERVER_URL}/api/v1/namespaces/default/pods/busybox

0 + 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Use .kube/config Client certs in curl

TH: ใช้ .kube/config Client certs ใน curl

RO: Utilizați certificatele client .kube/config în curl

RU: Используйте клиентские сертификаты .kube/config в curl

VI: Sử dụng .kube/config Client certs trong curl

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.