Answers: <p>This is something I have implemented recently.</p>
  <p><em><strong>NOTE: I'm assuming you are aware ho to add users. or users in group in this case.</strong></em></p>
  <p>here is what I have applied:</p>
  <pre><code>apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: readonly_role
  rules: 
  - apiGroups:
    - &quot;&quot;
    resourceNames:
    - &quot;&quot;
    resources:
    - &quot;pods&quot;
    - &quot;pods/logs&quot;
    - &quot;deployments&quot;
    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
  
  </code></pre>
  <p>You can use either <code>ClusterRole</code> &amp; <code>ClusterRoleBinding</code> or else just <code>Role</code> &amp; <code>Rolebinding</code>, 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 <code>Role</code> &amp; <code>Rolebinding</code> kind of object.</p>
  <p><strong>What I'm doing/creating in the above?</strong></p>
  <p>I'm creating one RBAC Role (<code>readonly_role</code>) scoped to Cluster.
  and in that I'm specifying I want to let access <code>pods</code>, <code>logs</code> (i.e <code>pods/logs</code>), and <code>deployments</code>. additionally you. can also add things like <code>services</code> or else if you just want to give access to all specify <code>&quot;&quot;</code> instead.</p>
  <p>in the 2nd part, I'm creating a ClusterRoleBinding Object named <code>bind_readonly_dev_role </code> which ensures only users in group <code>myorg:readonly</code> are having this role or privileges in the role we just created (<code>readonly_role </code>).</p>
  <p>NOTE: Incase you want to allow proxy access to certain applications, like <code>kubectl proxy</code>.
  you might have to specify them separately in the <code>ClusterRole</code> rules.</p>
  <p>I do like this for one of my svc:</p>
  <pre><code>- apiGroups:
    - &quot;&quot;
    resourceNames:
    - dashboard:5000
    resources:
    - services/proxy
    verbs:
    - '*'
  
  </code></pre>
  <p>at last but not least, you have to test if the user has those privileges correct,
  you can test like this:</p>
  <pre><code>kubectl auth  can-i get pods --as myorg:readonly
  </code></pre>
  <p>in the above replace the pods with the object you want the users of the group to have access to.</p>
  <p>Hope this helps!</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-01-01T14:04:41.290Z
Answers: Thanks @Saikat. Is group myorg:readonly to be created as Linux group "readonly". And is myorg constant. Sorry I am not much aware of group subject.
Answers: Navi
Answers: CC BY-SA 4.0
Answers: 2021-01-01T15:12:45.440Z
Answers: I guess you are talking about the users who access k8s, correct me if I'm wrong? here I'm not talking about the k8s user group and k8s role. Linux users are different.
Answers: Saikat Chakrabortty
Answers: CC BY-SA 4.0
Answers: 2021-01-01T15:17:44.407Z
Answers: I am talking about linux users and linux group. And k8s role based on linux group. Btw, do u hv any link on how to create k8s user group and add user to group.
Answers: Navi
Answers: CC BY-SA 4.0
Answers: 2021-01-01T15:24:57.967Z
Answers: you can find create user doc here: https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md
Answers: Saikat Chakrabortty
Answers: CC BY-SA 4.0
Answers: 2021-01-01T13:59:08.490Z
Answers: 2021-01-01T13:59:08.490Z
Answers: Saikat Chakrabortty
Answers: <p>The title of the question is &quot;Group authentication in kubernetes&quot; and the original poster asked in the comments &quot;Do you have any link on how to create k8s user group and add user to group&quot;.   So it could be helpful to answer:</p>
  <p><strong>How do you add kubernetes users into groups?</strong></p>
  <p>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.</p>
  <p>That means you first must determine your authentication method. For example, &quot;I'm using X509 Client Certs&quot; or &quot;I'm using a service account token&quot;. That answer can't be &quot;Probably I am just using the default built-in kubernetes users and groups&quot; because unfortunately that's something which doesn't exist.</p>
  <p>Based on the authentication method, here are alternative ways to set the 'group'.</p>
  <p>(Most of this is taken verbatim from <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/" rel="nofollow noreferrer">https://kubernetes.io/docs/reference/access-authn-authz/authentication/</a> with some editing and rearranging for clarity).</p>
  <p><strong>X509 Client Certs:</strong></p>
  <p>Place the group names in the certification signing request:</p>
  <pre><code>openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj &quot;/CN=jbeda/O=app1/O=app2&quot;
  </code></pre>
  <p>This would create a CSR for the username &quot;jbeda&quot;, belonging to two groups, &quot;app1&quot; and &quot;app2&quot;.</p>
  <p><strong>Static Token File:</strong></p>
  <p>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.</p>
  <p>Note:
  If you have more than one group the column must be double quoted e.g.</p>
  <pre><code>token,user,uid,&quot;group1,group2,group3&quot;
  </code></pre>
  <p><strong>Bootstrap Tokens:</strong></p>
  <p>The authenticator authenticates as system:bootstrap:Token ID. It is included in the system:bootstrappers group. The naming and groups are intentionally limited.</p>
  <p><strong>OpenID Connect Tokens:</strong></p>
  <p>When configuring the API Server to support OpenID Connect Tokens, add this flag</p>
  <pre><code>--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
  </code></pre>
  <p>The identity provider would include 'groups' in the token.</p>
  <p><strong>Webhook Token Authentication:</strong></p>
  <p>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:</p>
  <pre><code> # Optional group memberships
        &quot;groups&quot;: [&quot;developers&quot;, &quot;qa&quot;],
  </code></pre>
  <p><strong>Authenticating Proxy:</strong></p>
  <p>Configure the API server with this flag:</p>
  <pre><code>--requestheader-group-headers 1.6+. Optional, case-insensitive. &quot;X-Remote-Group&quot; is suggested. Header names to check, in order, for the user's groups. All values in all specified headers are used as group names.
  </code></pre>
  <p>Send an http request with X-Remote-Group included in the headers.</p>
  <pre><code>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
  </code></pre>
  <p><strong>Anonymous requests:</strong></p>
  <p>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.</p>
  <p><strong>User impersonation:</strong></p>
  <p>A user can act as another user through impersonation headers.
  The following HTTP headers can be used to performing an impersonation request:</p>
  <pre><code>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 &quot;Impersonate-User&quot;.
  </code></pre>
  <p><strong>client-go credential plugins:</strong></p>
  <p>Interacts with an external service (LDAP, Kerberos, OAuth2, SAML, etc.).</p>
  <p>During the authentication process, the &quot;external service verifies the signature on the token and returns the user's username and groups.&quot;</p>
  <hr />
  <p>source information from <a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/" rel="nofollow noreferrer">https://kubernetes.io/docs/reference/access-authn-authz/authentication/</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2022-06-30T17:35:50.447Z
Answers: This is a direct copy of your source, without quote.
Answers: Evan Carroll
Answers: CC BY-SA 4.0
Answers: 2022-06-30T17:56:00.550Z
Answers: ok, I just added another comment, so the reference to kubernetes.io is at there twice now.   It is a "selection" of specifically the group related information taken from that article.  If that still invalidates the answer, maybe it should be deleted, not sure.
Answers: Sam
Answers: CC BY-SA 4.0
Answers: 2022-06-30T16:35:05.313Z
Answers: 2022-06-30T17:50:38.033Z
Answers: 2022-06-30T17:50:38.033Z
Answers: Sam
Body: <p>I am trying to implement group based authentication in k8s with RBAC. My requirement is as below:</p>
  <p>There is a linux group named &quot;readonly&quot;. There are 3 users reader1, reader2 and reader3 in readonly group.</p>
  <p>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.</p>
  <p>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</p>
  <p>Thanks.</p>
  
Comments: CC BY-SA 4.0
Comments: 2021-01-01T15:26:51.220Z
Comments: can explain a bit more? It's not clear what the Linux group would do in k8s? do you mean creating groups in Linux nodes? or just k8s users and groups you are talking about? or whats the relation between Linux group and k8s RBAC in here?
Comments: Saikat Chakrabortty
Tags: <docker><kubernetes>
Title: Group authentication in kubernetes
UserDisplayName: Navi
ThreadText: # Group authentication in kubernetes
  
  (Asked by: username_0 on 2020-12-28)
  
  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.
  
  **Tags:** docker, kubernetes
  
  > **Comments:**
  > **username_1**: can explain a bit more? It's not clear what the Linux group would do in k8s? do you mean creating groups in Linux nodes? or just k8s users and groups you are talking about? or whats the relation between Linux group and k8s RBAC in here?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2021-01-01. Score: 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!
  
  > **Comments:**
  > **username_0**: Thanks @username_1. Is group myorg:readonly to be created as Linux group "readonly". And is myorg constant. Sorry I am not much aware of group subject.  
  > **username_1**: I guess you are talking about the users who access k8s, correct me if I'm wrong? here I'm not talking about the k8s user group and k8s role. Linux users are different.  
  > **username_0**: I am talking about linux users and linux group. And k8s role based on linux group. Btw, do u hv any link on how to create k8s user group and add user to group.  
  > **username_1**: you can find create user doc here: https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md  
  
  ---
  
  ### Answer by username_2 on 2022-06-30. Score: 0
  
  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/>
  
  > **Comments:**
  > **username_3**: This is a direct copy of your source, without quote.  
  > **username_2**: ok, I just added another comment, so the reference to kubernetes.io is at there twice now.   It is a "selection" of specifically the group related information taken from that article.  If that still invalidates the answer, maybe it should be deleted, not sure.  
  
  ---
  
  