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/
Related
I am looking for a way to create/retrieve/update/delete a user in Kubernetes, such that I can allow him certain stuff via RoleBindings.
Everything I have found is more or less manual work on the master node. However, I imagine a service deployed in Kubernetes I could call via an API to do the magic for me without doing any manual work. Is such a thing available?
From https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes
All Kubernetes clusters have two categories of users: service accounts
managed by Kubernetes, and normal users.
Kubernetes does not have objects which represent
normal user accounts. Normal users cannot be added to a cluster
through an API call.
Even though a normal user cannot be added via an API call, any user
that presents a valid certificate signed by the cluster's certificate
authority (CA) is considered authenticated.
So there is no API call to create normal user. However you can create service accounts that can have RoleBindings bound to them.
Another possibility is to create TLS certificate, sign it with Kubernetes cluster CA (using CSRs) and use it as a "normal user".
There are 2 commands I am confused for some time:
gcloud iam service-accounts get-iam-policy
gcloud iam service-accounts set-iam-policy
from the --help command, these 2 commands treat service account as a resource, most often I use service account as an identity, for example, in a project, set policy by binding role with service account so this service account can operate on something in that project.
Can someone please point out what is the usage to attach the policy to service account? how does service account act as a resource rather than an identity?
As explained in this below part of the official documentation Managing service accounts
:
When thinking of a service account as a resource, you can grant roles to other users to access or manage that service account.
So, use it as a resource has to goal for you to manage who can use and control the service account. To provide some additional details, as in this example here, with the policies attached to them, you can configure the level of access that different users can have within service accounts - as mentioned there, you can configure that some users have viewer access, while others have editor level.
To summarize, the functinality of attaching policies to a service account is for you to set different levels of access and permissions to users who can access the service account.
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.
kube-apiserver does not seem to provide an option to use a certification revocation list (CRL).
Is there a way to revoke a client certificate if it's lost or not used anymore?
As far as I know there isn't a way to directly revoke certificates via a CRL. However, what does work, and what we are currently using, is ABAC policies to identify users (set via the Common Name of a certificate), and whether they have access to a given resource on Kubernetes.
As an example, say you have a user called "random". You would generate a Client Certificate for them from your given Certificate Authority, with a Common Name of "random".
From there, you can have an ABAC policy file (a csv file with each line being a bit of JSON), with permissions set for user "random" that would provide them with a certain level of access to the Kubernetes API. You can have them have access to everything or certain namespaces or other API parameters. If you need to revoke permissions, you simply delete that user from the ABAC policy file. We've tested this, and it works well. The unfortunate thing, I will say, is you have to restart the Kubernetes API service for those changes to take effect, so there may be a few seconds of downtime for this change to occur. Obviously in a development environment this isn't a big deal, but on production you may need to schedule time for users to be added.
Hopefully in the future a simple "kube-apiserver reload" will allow for a re-read of that ABAC policy file.
One final thing to note: when using Client Certificates for ABAC authentication, you will need to set permissions for users INDIVIDUALLY. Unlike with auth tokens with ABAC, you cannot set Client Certificate users in "groups." Something that caused us headaches, so figured it was worth passing on. :)
Hope this helps!