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
Related
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.
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.
Does anyone know if this change https://github.com/kubernetes/kubernetes/pull/72179 will affect the service account tokens and their ability not to expire? Right now we have such tokens in our CI/CD and we rely that these will not expire.
According to this
This only changes the source of the credentials used by the controller loops started by the kube-controller-manager process. Existing use of tokens retrieved from secrets is not affected.
I want to create base authentication in kubernetes. every document say that I should create CSV or file then enter the username and password in it. but I do not want to use file I want to some database or kubernetes handle it.
what can I do for base authentication?
You can based your authentication on tokens if you don't want to use static pasword file.
First option:
Service Account Tokens
A service account is an automatically enabled authenticator that uses signed bearer tokens to verify requests.
The plugin uses two flags(which are optional):
Service accounts are usually created automatically by the API server and associated with pods running in the cluster through the ServiceAccount Admission Controller. Bearer tokens are mounted into pods at well-known locations, and allow in-cluster processes to talk to the API server. Accounts may be explicitly associated with pods using the serviceAccountName field of a PodSpec.
Service account bearer tokens are perfectly valid to use outside the cluster and can be used to create identities for long standing jobs that wish to talk to the Kubernetes API. To manually create a service account, simply use the kubectl create serviceaccount (NAME) command. This creates a service account in the current namespace and an associated secret.
The created secret holds the public CA of the API server and a signed JSON Web Token (JWT).
The signed JWT can be used as a bearer token to authenticate as the given service account. See above for how the token is included in a request. Normally these secrets are mounted into pods for in-cluster access to the API server, but can be used from outside the cluster as well.
There is some drawbacks because service account tokens are stored in secrets, any user with read access to those secrets can authenticate as the service account. Be careful when granting permissions to service accounts and read capabilities for secrets.
Second:
Install OpenID Connect (full documentation you can find here: oidc).
OpenID Connect (OIDC) is a superset of OAuth2 supported by some service providers, notably Azure Active Directory, Salesforce, and Google. The protocol’s main addition on top of OAuth2 is a field returned with the access token called an ID Token. This token is a JSON Web Token (JWT) with well known fields, such as a user’s email, signed by the server.
To identify the user, the authenticator uses the id_token (not the access_token) from the OAuth2 token response as a bearer token.
Since all of the data needed to validate who you are is in the id_token, Kubernetes doesn’t need to “phone home” to the identity provider. In a model where every request is stateless this provides a very scalable solution for authentication.
Kubernetes has no “web interface” to trigger the authentication process. There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first.
There’s no easy way to authenticate to the Kubernetes dashboard without using the kubectl proxy command or a reverse proxy that injects the id_token.
More information you can find here: kubernetes-authentication.
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/