When we setup a kubernetes master using kubeadm init . At the end of the procedure we have to copy the /etc/kubernetes/admin.conf to $home/.kube/config .
When I opened the file , I found the below details .
certificate authority data
client certificate data
client key data
I am aware the file is used for authentication when we try to access cluster using kubectl .
What I am trying to understand is from where these details are generated ? .
You have two options
- Use the automatically generated certificates if you have installed k8s with kubeadm
- Create your own certificates.
Once you have the certificates, you can follow these steps to manually configure them
https://kubernetes.io/docs/setup/certificates/#configure-certificates-manually
To create your own CA certificates, there are many google links and here is one for your reference.
http://pages.cs.wisc.edu/~zmiller/ca-howto/
If you are new to this, I would suggest you start with "A Single-level CA"
Related
I need to rotate admin.conf for a cluster so old users who used that as their kubeconfig wouldn't be allowed to perform actions anymore.
How can i do that?
This is a Community Wiki answer, posted for better visibility, so feel free to edit it and add any additional details you consider important.
As mdaniel wrote in his comment:
the answer to your question is "rekey the entire apiserver CA
hierarchy" or wait for admin.conf cert to expire, because those
admin.conf credentials are absolute. Next time, use the provided
oidc mechanism for user auth.
For kubeadm based kubernetes cluster please also refer to Certificate Management with kubeadm. For manual rotation of CA Certificates, please refer to this section. Pay special attention to point 7:
Update certificates for user accounts by replacing the content of client-certificate-data and client-key-data respectively.
For information about creating certificates for individual user
accounts, see Configure certificates for user accounts.
Additionally, update the certificate-authority-data section in the
kubeconfig files, respectively with Base64-encoded old and new
certificate authority data
I'm fairly new to kubernetes, so forgive me for my ignorance on this topic.
I am trying to set up x509 authentication in keycloak. This guide indicates that I need to edit a standalone.xml file and add my configurations there.
I'm not too sure how to edit this file on launch of the instance and copy my Java Key Store into the container image.
Replica of How to edit standalone.xml file dynamically in keycloak
You're going to need to dynamically create a keycloak image, then use that image for your configs.
I have followed the getting started instructions here: https://linkerd.io/2/getting-started/ for installing linkerd but i am not able to install cli of linkerd.
Please see the command below: curl -sL https://run.linkerd.io/install | sh
Please see the error below:
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option
Can anyone please help me to solve it.
The provides installation instructions from the Linkerd website are indeed vague, they provide instruction for Linux (shell) users as well as a brew install command for OSX users.
If you are interested in installing LinkerD on your Windows machine, the recommandation is to download the binary (.exe - for Windows) directly form their release page: https://github.com/linkerd/linkerd2/releases
After you have downloaded the binary, you should be able to update your %PATH% environment variable to add the location of the binary, this will allow you to refer to the linkerd directly from your command prompt.
Linkerd started supporting Windows with a Chocolatey package: https://chocolatey.org/packages/Linkerd2
To use it, make sure that you have Chocolatey installed and run:
choco install linkerd2
After the installation, verify that the install was successful with:
linkerd --help
You should see the list of commands available to the Linkerd CLI.
I installed a self-hosted Gitlab using the Helm chart on a Kubernetes cluster.
Everything is working fine except one thing: the cache.
In my .gitlab-ci.yml file I have
cache:
paths:
- .m2/repository/
- target/
But when running the job I have this warning when trying to download the cache:
WARNING: Retrying...
error=Get https://minio.mydomain.com/runner-cache/gitlab-runner/project/6/default?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=xxx: x509: certificate signed by unknown authority
And when uploading I have:
WARNING: Retrying... error=received: 501 Not Implemented
Uploading cache.zip to https://minio.mydomain.com/runner-cache/gitlab-runner/project/6/default
FATAL: received: 501 Not Implemented
But the certificate is provided by LetsEncrypt so it's not an unknown authority. When I go on minio.mydomain.com I can see that the connection is secure
I've also check that the runner is using the right credentials and yes it is.
I'm kind of lost here. Any hints is welcome.
Thanks.
You need to add the CA to the image that is hosting the cache.
You can follow these instructions from this gitlab issue for a workaround:
Update the helper image to have the ca chain for the self-signed certificate trusted.
FROM gitlab/gitlab-runner-helper:x86_64-latest
RUN apk add --no-cache ca-certificates
COPY ca.crt /usr/local/share/ca-certificates/ca.crt
RUN update-ca-certificates
RUN rm /usr/local/share/ca-certificates/ca.crt
docker build -t registry.gitlab.com/namespace/project/tools/gitlab-runner-helper:$SOME_TAG
Override the helper image used by GitLab by updating the config.toml to use the image you just build with the correct CA trusted.
If you are using the helm chart you can define KUBERNETES_HELPER_CPU_LIMIT environment variable and define it in envVars
Hope this helps.
i'm having trouble finding how I can add a trusted host using kcadm cli tool. This is in realm->realm settings->client registration->client registration policies->trusted hosts
it's part of components.
kcadm get components -r demorealm -F "name,id,config(*)" -q name="Trusted Hosts"
I found that if you export the database, it will produce a json file and you will find all the information that you need there.