Quartz 5

Role Based Access Control

Properties1
tagsinfrastructure/kubernetes

3 min read

Role Based Access Control

APIs

the kube-API server has endpoints through which you can query the cluster about it’s information, some endpoints are

  • /version - this endpoint returns the version of the kubernetes cluster
  • /api this gives information on all the core APIs
  • /apis this gives information on all the other named API, all the new versions of kubernetes will move to this named versioning system
    when you query using curl to these endpoints you will get a 403 Error as you are not a authorised user.
    in order to use query the endpoints you have to pass your user credentials every time, but this can be simplified when you use kubectl proxy as when you use this, this creates a proxy server which automatically adds your authentication headers to allow a smooth operation.

Key Takeaways

  • all resources in Kubernetes are grouped in API groups
    • the core API
    • the named API
      • the named API has many sub sections and each has an endpoint for each resource which can be altered with actions called as verbs

Do not confuse between the two

kubeproxy != kubectl proxy

we would like to give the minimum access as possible to any account that needs access to the cluster.

Authorization Mechanisms

There 4 types of authorizations

Node Authorization

Node Authorization

Link to original

In node authorization the Kubelet in the cluster has access to the kube-api server through the TLS certificates, it can, as the kubelet is part of the system node group

Attribute Based Access Control (ABAC)

In attribute based access control each user has a given set of permissions through a policy file in json, each file has to be created every time a new user is created or permissions need to be granted.

Attribute Based Access Conrol

Link to original

Role Based Access Control (RBAC)

Role Based Access Control

Link to original

In RBAC, we create roles with certain permissions, and we assign users to this role, this is a more standard approach to manage access controls in the cluster using Config Map

Controls

WebHooks

If you want to externally manage all the authorization in your cluster it can be done through webhooks, using third party tools such as Open Policy Agent, which when requested with user information gives information on what the user can do and cannot do

Always Allow and Always Deny

the authorization mode on the cluster is always Always Allow it can be changed to a comma seperated values to define the order to check for authorization, as soon as the request is authorized the access to the resources is provided to the user / requesting party

Always Allow - Always Deny

Link to original

Graph View

Backlinks