Group authentication in kubernetes

Question

I am trying to implement group based authentication in k8s with RBAC. My requirement is as below:

There is a linux group named "readonly". There are 3 users reader1, reader2 and reader3 in readonly group.

How can I implement the RBAC to give readonly access to all the users who are part of that group and all the future users who will become part of that group ? Readonly access means, access to list, get and watch resources using kubectl.

I came across .subjects[0].kind: Group in clusterrolebinding. But not sure how can that be used or if that can even be used for the above scenario

Thanks.

Answer 1

This is something I have implemented recently.

NOTE: I'm assuming you are aware ho to add users. or users in group in this case.

here is what I have applied:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: readonly_role
rules: 
- apiGroups:
  - ""
  resourceNames:
  - ""
  resources:
  - "pods"
  - "pods/logs"
  - "deployments"
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - authorization.k8s.io
  resources:
  - selfsubjectaccessreviews
  - selfsubjectrulesreviews
  verbs:
  - watch
  - get
  - list

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bind_readonly_dev_role
subjects:
- kind: Group
  name: myorg:readonly 
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: readonly_role
  apiGroup: rbac.authorization.k8s.io

You can use either ClusterRole & ClusterRoleBinding or else just Role & Rolebinding, depending on your requirement. In case you are not looking for cluster scoped access, instead just a namespace, I would strongly suggest going with the Role & Rolebinding kind of object.

What I'm doing/creating in the above?

I'm creating one RBAC Role (readonly_role) scoped to Cluster. and in that I'm specifying I want to let access pods, logs (i.e pods/logs), and deployments. additionally you. can also add things like services or else if you just want to give access to all specify "" instead.

in the 2nd part, I'm creating a ClusterRoleBinding Object named bind_readonly_dev_role which ensures only users in group myorg:readonly are having this role or privileges in the role we just created (readonly_role ).

NOTE: Incase you want to allow proxy access to certain applications, like kubectl proxy. you might have to specify them separately in the ClusterRole rules.

I do like this for one of my svc:

- apiGroups:
  - ""
  resourceNames:
  - dashboard:5000
  resources:
  - services/proxy
  verbs:
  - '*'

at last but not least, you have to test if the user has those privileges correct, you can test like this:

kubectl auth  can-i get pods --as myorg:readonly

in the above replace the pods with the object you want the users of the group to have access to.

Hope this helps!

Answer 2

The title of the question is "Group authentication in kubernetes" and the original poster asked in the comments "Do you have any link on how to create k8s user group and add user to group". So it could be helpful to answer:

How do you add kubernetes users into groups?

Kubernetes doesn't store usernames and groups in its local database, in a way that's analogous to most other systems. Instead, it depends on being provided the 'username' or 'group' by whatever your preferred authentication mechanism is. Depending upon which method you are using, the way to specify the group differs.

That means you first must determine your authentication method. For example, "I'm using X509 Client Certs" or "I'm using a service account token". That answer can't be "Probably I am just using the default built-in kubernetes users and groups" because unfortunately that's something which doesn't exist.

Based on the authentication method, here are alternative ways to set the 'group'.

(Most of this is taken verbatim from https://kubernetes.io/docs/reference/access-authn-authz/authentication/ with some editing and rearranging for clarity).

X509 Client Certs:

Place the group names in the certification signing request:

openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"

This would create a CSR for the username "jbeda", belonging to two groups, "app1" and "app2".

Static Token File:

The API server reads bearer tokens from a file when given the --token-auth-file=SOMEFILE option on the command line. The token file is a csv file with a minimum of 3 columns: token, user name, user uid, followed by optional group names.

Note: If you have more than one group the column must be double quoted e.g.

token,user,uid,"group1,group2,group3"

Bootstrap Tokens:

The authenticator authenticates as system:bootstrap:Token ID. It is included in the system:bootstrappers group. The naming and groups are intentionally limited.

OpenID Connect Tokens:

When configuring the API Server to support OpenID Connect Tokens, add this flag

--oidc-groups-claim JWT claim to use as the user's group. If the claim is present it must be an array of strings.   Example: groups Required: No

The identity provider would include 'groups' in the token.

Webhook Token Authentication:

The API server is configured to communication with a remote authentication service. That external service should return a validation in json format that may include an optional group membership:

 # Optional group memberships
      "groups": ["developers", "qa"],

Authenticating Proxy:

Configure the API server with this flag:

--requestheader-group-headers 1.6+. Optional, case-insensitive. "X-Remote-Group" is suggested. Header names to check, in order, for the user's groups. All values in all specified headers are used as group names.

Send an http request with X-Remote-Group included in the headers.

GET / HTTP/1.1
X-Remote-User: fido
X-Remote-Group: dogs
X-Remote-Group: dachshunds
X-Remote-Extra-Acme.com%2Fproject: some-project
X-Remote-Extra-Scopes: openid
X-Remote-Extra-Scopes: profile

Anonymous requests:

When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests, and given a username of system:anonymous and a group of system:unauthenticated.

User impersonation:

A user can act as another user through impersonation headers. The following HTTP headers can be used to performing an impersonation request:

Impersonate-User: The username to act as.
Impersonate-Group: A group name to act as. Can be provided multiple times to set multiple groups. Optional. Requires "Impersonate-User".

client-go credential plugins:

Interacts with an external service (LDAP, Kerberos, OAuth2, SAML, etc.).

During the authentication process, the "external service verifies the signature on the token and returns the user's username and groups."

---

source information from https://kubernetes.io/docs/reference/access-authn-authz/authentication/