So I've gone through the process of generating an RSA key, creating the YAML for a CSR, using kubectl to create a CSR in Minikube, approved the certificate.
However, when I try to download the certificate using kubectl get csr my-csr -o jsonpath='{.status.certificate}' I'm getting an empty result.
When I do a kubectl get csr my-csr -o yaml to get more information, this is what I see:
status:
conditions:
- lastUpdateTime: "2020-01-17T20:17:20Z"
message: This CSR was approved by kubectl certificate approve.
reason: KubectlApprove
type: Approved
I'm expecting a certificate attribute with a base64 encoded string to which I will decode to obtain the certificate for client certificate validation. Can someone please tell me what I'm doing wrong?
For more context, I'm trying to follow the instructions in this tutorial
I got similar problem. When I check with the following command:
kubectl get svc
It seems that the status of the csr is approved, but not issued. Any idea how to fix it?
[Updated]
I found the problem. It is because the kube-controller-manager missed these options:
--cluster-signing-cert-file and --cluster-signing-key-file
Since CSR is not namespace specific, the command looks fine. I did the same to get the certificate, check you provide the proper csr name properly.
Secondly, if you didn't provide the name, and try to get all csr detail, you need change the key structure with additional .items[*]
kubectl get csr -o jsonpath='{.items[*].status.certificate}'
I have the feeling, you missed the csr name my-csr or the name is not really matched the search (typo?). Double check it.
This error must come. From the docs
Permitted subjects - organizations are exactly ["system:nodes"], common name starts with "system:node:".
So the solution is to add subjects O=system:nodes and appending "system:node:" to your servicename in cert generation.
For ex.
openssl req -new -key server.key -out server.csr -subj "/O=system:nodes/CN=system:node:colortokens-bgl.csp.svc" -config server.conf
Verify your controller manager config, the Controller manager must be provided with --cluster-signing-cert-file and --cluster-signing-key-file config in-order to sigh the csr.
https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kube-controller-manager-configuration
ex:
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
controllerManager:
extraArgs:
cluster-signing-cert-file: /etc/kubernetes/pki/ca.crt
cluster-signing-key-file: /etc/kubernetes/pki/ca.key
For my case, I had a typo error
WithTypo: signerName: kubernetes.io/kube-apisever-client
WithoutTypo: signerName: kubernetes.io/kube-apiserver-client
and have the same result. csr was approved and certificate was not issued. It was resolved after I corrected the typo error.
Related
My deployment yaml file has 2 images;
1) redis:alpine it works fine
2) Openshift pulls image from my own harbor registry
My harbor registry has ssl (not self sign) certificate.
I can login to my harbor registry, pull, push images as a container without getting an error.
But openshift has problem to pull my image from my harbor registry.
oc describe pod <mypodname>
prints this error
Failed to pull image <myregistry.net<myrepo><myimage><mytag>> : rpc error: code = Unknown desc = pinging container registry myregistry.net: Get "https://<myregistry>.net/v2/": x509: certificate signed by unknown authority
I have ca.crt under /etc/docker/certs.d/myregistry
I tried https://docs.openshift.com/container-platform/4.7/cicd/builds/setting-up-trusted-ca.html#configmap-adding-ca_setting-up-trusted-ca this solution, did not work for me.
Any help would be appreciated. Thanks in advance
If you followed the above doc, it should work.
$ oc patch proxies.config.openshift.io/cluster --type=merge -p '{"spec":{"trustedCA":{"name":"user-ca-bundle"}}}'
$ oc -n openshift-config create configmap user-ca-bundle --from-file=ca-bundle.crt=xxx/rootCA.pem
I was trying to automate the process of signing Kubernetes certificates for new users.
The official documentation (here) suggests using Kubectl. In particular they suggest using the command :
kubectl certificate approve csr_name
and obtain a base64 encoded certificate via :
kubectl get csr/csr_name -o yaml
and looking at the status.certificate field. Since I have access to the cluster certificates ( at /etc/kubernetes/pki) and since I wanted to further automate the process I was wondering which certificate and key are used by Kubernetes in the signing process. I've tried with apiserver, ca and kubeadmin (.crt and .key) and openssl as follows :
openssl x509 -req my.csr -days 365 -CA /etc/kubernetes/*.crt -CAkey /etc/kubernetes/*.key -CAcreateserial -out my.crt
where *.crt and *.key are the various files mentioned above. But the results are always different from that of the kubectl command. Any idea what I am missing?
Thanks in advance!
Very partial answer for this moment
1. CA for etcd, kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, and kube-proxy
Since I have access to the cluster certificates ( at
/etc/kubernetes/pki) and since I wanted to further automate the
process I was wondering which certificate and key are used by
Kubernetes in the signing process.
There is a great Kubernetes The Hard Way tutotial that give you great opportunity to check,test and try by your own how to manually create kubernetes cluster using manually create all the certificates for core resources.
Provisioning a CA and Generating TLS Certificates
you will provision a PKI Infrastructure using CloudFlare's PKI
toolkit, cfssl, then use it to bootstrap a Certificate Authority, and
generate TLS certificates for the following components: etcd,
kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, and
kube-proxy.
Generating Kubernetes Configuration Files for Authentication
you will generate Kubernetes configuration files, also known as
kubeconfigs, which enable Kubernetes clients to locate and
authenticate to the Kubernetes API Servers.
2. New user creation
you can use Kubernetes: How do I access the CA to sign a new user certificate? as a reference. Copy pasting for history in case original post would be removed
you can use the build in CA in your cluster to create client
certificates. Background information on how to use the CA:
https://kubernetes.io/docs/concepts/cluster-administration/certificates/
Assuming you have a user.json
{
"CN": "mfrank",
"key": {
"algo": "rsa",
"size": 4096
},
"names": [{
"O": "mfrank",
"email": "some#email"
}]
}
You can then generate a CSR for this. In this example I use cfssl to
generate the CSR:
cfssl genkey user.json | cfssljson -bare client
You can now use kubectl to submit a CSR for your cluster:
cat <<EOF | kubectl create -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
name: mfrank
spec:
groups:
- system:authenticated
- mfrank
request: $(cat client.csr | base64 | tr -d '\n')
usages:
- digital signature
- key encipherment
- client auth
EOF
The request field is base64 encoded version of your csr file.
To view your CSR: kubectl get csr
To approve it:
kubectl certificate approve mfrank
Decode it:
kubectl get csr mfrank -o jsonpath='{.status.certificate}' | base64 -d > client.pem
You can now use the client-key.pem and client.pem to build a
kubeconfig.
You can then create RBAC rolebindings on your cluster assigning to
either –user=mfrank or –group=mfrank (assuming you used “O”: “mfrank”)
Hi I have IBM cloud private cluster up and running.
I try login with cloudctl login https://icp-console.example.co.id
Everything is fine, the last line show me:
Configuring helm: /root/.helm
OK
But when i try to inspect the certificate generated in /root/.helm/cert.pem:
Certificate Information:
Common Name: admin
Valid From: November 9, 2020
Valid To: February 7, 2021
Issuer: www.ibm.com, IBM Cloud Private
It shows me above Information. I would like to know, how to extend the certificate generated from command cloudctl login, because its only effective for 3 months ?
If possible I would like to make it 10 years, or maybe never expire.
Please help..
I Solved it my self,
get certificate cert.pem from helm-tiller-secret,
oc get secret -n kube-system helm-tiller-secret -o go-template --template="{{.data.crt|base64decode}}"
get certificate key.pem from helm-tiller-secret,
oc get secret -n kube-system helm-tiller-secret -o go-template --template="{{.data.key|base64decode}}"
copy and paste it to /root/.helm/cert.pem and /root/.helm/key.pem
If you want to, you can also create new secret, if some namespace is required a connection to helm with this command:
kubectl create secret generic apic-ent-helm-tls --from-file=cert.pem=/root/.helm/cert.pem --from-file=ca.pem=/root/.helm/ca.pem --from-file=key.pem=/root/.helm/key.pem -n
I am new to kubernetes. I created a certificate in kubernetes for my validation webhook.
After approving the certificate, and checking if it is still there after few hours, by running
kubectl -n mynamespace get csr
However, it shows no resources found in the namespace. But if the certificate is newly created
and run the same command above it shows the certificate.
Is this an expected behavior? where does the certificate go?
Please help. :(
This is an expected behavior for security reasons. You should download the certificate using below command and keep it safe.
kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
| base64 --decode > server.crt
https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/#download-the-certificate-and-use-it
csr is short for Certificate Signing Requests
It dismiss after validated.
If your want to check certificates:
kubectl get cert -A
-A for --all-namespaces
When running setup_robot.sh per the Cloud Robotics documentation, the certificate is not valid. I get the following error:
Failed to update robot CR my-robot: Failed to get robot my-robot: Get https://www.endpoints.robco-skopecki.cloud.goog/apis/core.kubernetes/apis/registry.cloudrobotics.com/v1alpha1/namespaces/default/robots/my-robot: x509: certificate is valid for ingress.local, not www.endpoints.robco-skopecki.cloud.goog
This problem occurs if letsencrypt did not finish creating the certificate for the cloud-cluster. This might happend during a first time install. Here is how you can check:
kubectl get certificates cloud-robotics -o yaml
If the output lacks a status, restart the cert-manager:
kubectl delete pod cert-manager-<tab>
Once it restarted, check the certificate again and once the status is indicating sucess, you should have your certificate stored as a secret called tls:
kubectl get secrets tls
At this point you can rerun setup_robot.sh.