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