Kubernetes RBAC[TODO]

RBAC

1. RBAC

RBAC model:

WHO DO WHAT

Subject Verbs Resources

In order to fully grasp the idea of RBAC, we must understand that three elements are involved:

Subjects: The set of users and processes that want to access the Kubernetes API.
Resources: The set of Kubernetes API Objects available in the cluster. Examples include Pods, Deployments, Services, Nodes, and PersistentVolumes, among others.
Verbs: The set of operations that can be executed to the resources above. Different verbs are available (examples: get, watch, create, delete, etc.), but ultimately all of them are Create, Read, Update or Delete (CRUD) operations.

Roles and Binding

So, if we think about connecting these three types of entities, we can understand the different RBAC API Objects available in Kubernetes.

  • Roles: Will connect API Resources and Verbs. These can be reused for different subjects. These are binded to one namespace (we cannot use wildcards to represent more than one, but we can deploy the same role object in different namespaces). If we want the role to be applied cluster-wide, the equivalent object is called ClusterRoles.

  • RoleBinding: Will connect the remaining entity-subjects. Given a role, which already binds API Objects and verbs, we will establish which subjects can use it. For the cluster-level, non-namespaced equivalent, there are ClusterRoleBindings.

2. RBAC on AWS EKS

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::803236244776:role/EKSNodeGroupRole
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::803236244776:role/EksCodeBuildRole
      username: codebuild
      groups:
        - system:masters
  mapUsers: |
    - userarn: arn:aws:iam::803236244776:user/hixichen
      username: hixichen
      groups:
        - system:masters

User and Group Map:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: {{ ClusterAdminRoleArn }}
      username: system:node:{{ '{{EC2PrivateDNSName}}' }}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::{{ AccountId }}:role/{{ AdminRoleName }}
      username: admin
      groups:
        - system:masters
    - rolearn: arn:aws:iam::{{ AccountId }}:role/{{ CIRoleName }}
      username: ci
      groups:
        - system:masters
    - rolearn: arn:aws:iam::{{ AccountId }}:role/{{ ViewRoleName }}
      username: view

Questions:

  • In which case we should use ABAC mode?

https://rbac.dev/ https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control https://kubernetes.io/docs/reference/access-authn-authz/rbac/ https://www.cncf.io/blog/2020/08/28/kubernetes-rbac-101-authorization/ https://octopus.com/blog/k8s-rbac-roles-and-bindings https://thenewstack.io/three-realistic-approaches-to-kubernetes-rbac/ https://github.com/alcideio/rbac-tool https://medium.com/containerum/configuring-permissions-in-kubernetes-with-rbac-a456a9717d5d https://www.eksworkshop.com/beginner/091_iam-groups/create-k8s-rbac/

RBAC sync: https://medium.com/cruise/open-sourcing-rbacsync-48758df685b0

Chen Xi
Chen Xi
Software Engineer

Related