Kubernetes Classroom Series – 02/Aug/2021

Managing RBAC in Source Control

• Like all resources in k8s, RBAC resources are modelled using JSON or YAML
• Since this is text based expression it makes sense to store these resources in version control. This will help for auditing, accountability and rollback changes for RBAC
• In kubectl command-line has a reconcile command that operates much like kubectl apply

kubectl auth reconcile -f some-rbac-config.yaml

Aggregating ClusterRoles

• Sometimes we want to be able to define roles that are combination of other roles. K8s RBAC supports the usage of aggregation rule to combine multiple roles together in a new role.
• Like all aggregations or grouping in K8s the ClusterRoles to be aggregated are specified using label selectors

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: learningrole
aggregationRule:
  clusterRoleSelectors:
    - matchLabels:
        rbac.authorization.k8s.io/aggregate-to-learn: "true"

Using Groups for Bindings

• To bind a ClusterRole we can use a Group kind for subject in Bindings

....
subjects:
- apiGroup: "rbac.authorization.k8s.io"
  kind: Group
  name: dev-group

Authentication

• Users in K8s:

  • Service Accounts (Managed by k8s)
  • Users

• It is assumed that a cluster-independent service manages normal users i.e. K8s doesn’t have a user database. Users live outside the cluster and are usually managed & controlled by the Cloud Provides

• K8s doesn’t have objects which represent normal user accounts.

• Eventhough a normal user cannot be added via an API call, any user that presents a valid certificated signed by the Clusters certificated Authority is considered authenticated. From there RBAC sub system would determine whether the user is authorized to perform specific operation on a resource or not

• Creating a Normal user: Refer Here

• Authentication Strategies: k8s uses client certificates, bearer tokens , an authentication proxy to authenticate API requests throught authentication plugins. As HTTP request are made to API server, Plugins attempt to associate the following attributes with the request

  • Username:
  • UID
  • Groups
  • Extra fields

• Azure Kubernetes Service (AKS): Refer Here

• AWS Elastic Kubernetes Service (EKS): Refer Here

• Google Kubernetes Engine (GKE): Refer Here

HELM

• In order to deploy an application on k8s we need to interact with k8s API to create resources, kubctl is the tool we use to do this
• We express Kubernetes resources in YAML Files
• These files are static in nature.
• Resource files are static:
  • This is the challenge that primarily effects the declarative configuration style of applying YAML resources
  • K8s YAML files are not designed to be parametrized
  • Consider the below two manifests writtent to deploy two different applications
  • In the above image each file is almost exactly the same, but we still cannot parametrize
• Helm to the rescue: Helm is an opensource tool used for packaging and deploying applications on k8s. It is often referred as Kubernetes Package Manager.
• Helm was designed to provide an experience similar to that of package manager (apt, yum, dnf etc)
• APT operates on debian packages and yum/dnf operates on RPM package.
• Helm operates on Charts.
• A Helm Chart contains declarative k8s resource files required to deploy an application
• Helm relies on repositories to provide access to charts
• Chart developers create declarative YAML files , package them into charts and publish them to chart repository
• End users then Helm to search for existing chart to deploy some app on to k8s
• Refer Here to view a sample usage of helm chart which installs mysql.