RBAC in K8s

Posted by Manish Panchmatia on Tuesday, June 23, 2020 Labels: , , ,

RBAC is all about

 Can "Subject" "Verb" "Object" at "Location"


Allowed operations are defined in the serverresources.json file per object.

 K8s admission controller extracts following from the incoming request to K8s API server

 1. HTTP Method. It can derive verb. E.g. POST is mapped with create. VERB

 2. From URI extract (1) API group and (2) resource. OBJECT

 3. From URI extract Namespace. LOCATION

 4. From authentication derive (1) User Name (2) Groups. SUBJECT. 

 Note: For creating new object, the URI does not contain name of the resource. RBAC is NOT about a resource with specific name can be created or not. 

 YAML

 1. Role. 

 It has namespace.
Rules. 
- VERB
- OBJECT = API group + Resource
Here resource are namespaced resource

 apiGroups: [""] //for core api groups with naem"api/"
resources: ["pods"]
verbs: ["get", "create", "update", "list", "delete", "watch"]
resourceNames: ["Pod_name1", "pod_name2"]

 2. RoleBinding

 It has:
LOCATION = namespace 
Reference to Role = LOCATION + VERB + OBJECT
SUBJECT = Kind (user | group | service account) + name

 Here suppose service account = sa in namespace myns then it is mentioned as
"serviceaccount=myns:sa"

 If we want to specify all service account in the namespace then do NOT use "serviceaccount=myns:*" We shall use: "group=system:serviceaccounts:myns"

 3. ClusterRole

 It does not have namespace.It is global role. so can be used in all namespaces. 
Resource inside ClusterRole can be either (1) namespaced resource or (2) resource with cluster scope (cluster wide resources) . E.g. 
- Nodes, 
- ClusterRole, 
- CluterRoleBinding, 
- CSR, 
- NS, 
- PV (note: PVC is namespaced based resource and PV is cluster wide resource)

 k api-resouces --namespaced=true
k api-resouces --namespaced=false

 RoleBinding can have reference to ClusterRole, instead of Role. 
Since RoleBinding has namespace, the ClusterRole is assigned locally to specific namespace only

 4. ClusterRoleBinding

 It does not have namespace. 

 It has reference to ClusterRole
It grants permission globally. 

 * So ClousterRole has multiple purpose
1. It is global role. It is used to grant permission to user A in namespace AA and user B in namespace BB. It is used in RoleBinding
2. It is for resource with cluster scope. E.g. Nodes, PV
3. It is used in ClusterRoleBinding to grand global permission. 
Note: namespaced permission and non-namespaced permission cannot be mixed in single cluster role.

 * ClusterRoleBinding can be for
- cluster scope resource
- granting global cluster wide permission. 

 Default Subjects
1. system:master is name of group. SUBJECT = user | group | service account. So group is SUBJECT
2. system:kube-scheduler , 
3. system:kube-control-manager, 
4. system:kube-proxy

kubelet runs with
5. username = system:node:"node name"
group = system:nodes
Here RBAC alone is not sufficient. So authorization mode is both: (1) RBAC and (2) Node. The Kubelet's client certificate is useful for (1) Node Authorizer and (2) Node Restriction Admission plugin

 Note: In client certificate username is called CN (Common Name) and group is called Organisations

 Default ClusterRole
1. cluster-admin is like super user
2. admin
3. edit
4. view
admin, edit and view are assigned for individual SUBJECT for specific namespace LOCATION
Resource aggregation is used for new CR and default role: admin, edit, view. 

 Verb Expansion

 List = List, Get, Watch
Update = Update, Patch

 Subresource

 HPA works on /scale subresource
controller works on /status subresource 

 Federatoin
1 . define centrally and sync all local k8s cluster
2. webhook points to RBAC of other K8s cluster

Limitations

* No validation. 
- user exist or not. 
- rules
- subject. 

Aggregate

We can add label to cluster role 
rbac.authorization.k8s.io/aggregate-to-EXISTING_CLUSTER_ROLE: "true"

Impersonation 

We can have role/clusterrole , where verb = impersonate is applicable to resources = users | greoups | sas

In HTTP header mandatory header is Impersonate-User. Rest all are Impersonate-* headers are optional. All optional headers Impersonate-Extra-* can be access in role/clusterrole as resource userextras/*

ImagePullSecrets

Create a new secrets name "dr" using
k create secret docker-registry -h

Now edit existing sa "testsa". At the end add
imagePullSecrets:
- name: dr

0 comments:

Post a Comment