We generate the kubeconfig for kubernetes cluster from a web UI. Some users are complaining that their kubeconfig file is not working. We need to know the expiry date of the token from kubeconfig file. We would want to advise the users to regenerate the kubeconfig if we know how long the kubeconfig is valid.
you can verify the configured expiry time of the kubeconfig token within the Rancher UI, under API & Keys . Once the token expires, you will be prompted to log in again upon executing kubectl commands against the cluster.
Please find the document for more information.
Related
I created a token for my service account using the command 'kubectl create token admin-user'. But after a while it becomes unusable and I have to create it again. How can I generate a token for my service account without expire time?
Try the token for one year using the below command. You can define duration as appropriate, say --duration=87600h for 10 years and so on
kubectl create token admin-user --duration=8760h
I started working in kubernetes and notice that there is one secret available in each namespace
# kubectl get secret
NAME TYPE DATA AGE
default-token-b2rzn kubernetes.io/service-account-token 3 506d
this default-token-XXXX is token for service account with used by making kube-api call.
I have to do same type of thing, like we have some Third-party API. To access that API, we need token, and that token expire every 12 hours. I am thinking to create new secret as ourapi-token-XXXX, which will hold the token and there might be CronJob or Daemon in kubernetes which will check its expire time and update the value.
Lets take example of AWS or GCP API Token. This need to be renew automatically.
Goal is, when you try to access Third-party API, you don't need to generate token manually and get the valid token from kubernetes secrets.
I have created a token using the command init. That token does not was create with the default ttl, and now it expired. It is possible to revalidate a expired token in kubernetes?
If I understand you correctly than yes, it is possible.
Take a look at the official documentation.
The token is used for mutual authentication between the control-plane
node and the joining nodes. The token included here is secret. Keep it
safe, because anyone with this token can add authenticated nodes to
your cluster. These tokens can be listed, created, and deleted with
the kubeadm token command. See the kubeadm reference guide.
From there you can use the kubeadm token generate [flags] command.
This command will print out a randomly-generated bootstrap token that
can be used with the “init” and “join” commands.
Please let me know if that helped.
I'm trying to access Kubernetes Dashboard via a kubeconfig file but I don't know how to create a kubeconfig file to access it.
I can access it by a token way but I want to access it by a kubeconfig file, too.
thanks
Can you explain what you mean when you say you can access it by token but not through a kubeconfig? Kubeconfigs simply store authentication information in them, which can include authentication via a token.
Assuming the rest of your kubeconfig file is populated, you just need to modify it so that your user information contains the token, like so:
users:
- name: my-user
user:
token: <token-here>
I have been confused for a long time about how the user of kubectl being authorized. I bootstrap a k8s cluster from scratch and use 'RBAC' as the authorization mode. The user kubectl used is authenticated by certificate first, then it should be authorized by RBAC when accessing the api-server. I did nothing about granting permissions to the user, however, it is allowed to access all the apis(creating pod or listing pods).
Kubernetes has no built in user management system. It expects you to implement that part on your own. In this sense, a common way to implement user auth is to create a certificate sign request and have it signed by the cluster certificate authority. By reading that newly generated certificate, the cluster will extract the username and the groups it belongs to. Then, after that, it will apply the RBAC policies you implemented. In this sense, if the user can access everything, then it can be one of the following:
You are still using the admin user account instead of the newly created user account.
The user account you created belongs to an admin group
You did not enable RBAC correctly
This guide should help you with an easy example of user auth in Kubernetes: https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/