RBAC Policies and Auditing

Authentication is only the first step in managing access to a cluster. Once access to a cluster is granted, it's important to limit what accounts can do, depending on whether an account is for an automated system or a user. Authorizing access to resources is an important part of protecting against both accidental issues and bad actors looking to abuse a cluster.

In this chapter, we're going to detail how Kubernetes authorizes access via its Role-Based Access Control (RBAC) model. The first part of this chapter will be a deep dive into how Kubernetes RBAC is configured, what options are available, and mapping the theory onto practical examples. Debugging and troubleshooting RBAC policies will be the focus of the second half.

In this chapter, we will cover the following topics:

• Introduction to RBAC
• Mapping enterprise identities to Kubernetes to authorize access to resources
• Namespace multi-tenancy
• Kubernetes auditing...

Technical requirements

This chapter has the following technical requirements:

• A KinD cluster running with the configuration from Chapter 5, Integrating Authentication into Your Cluster

You can access the code for this chapter at the following GitHub repository: https://github.com/PacktPublishing/Kubernetes---An-Enterprise-Guide-2E/tree/main/chapter6.

Introduction to RBAC

Before we jump into RBAC, let's take a quick look at the history of Kubernetes and access controls.

Before Kubernetes 1.6, access controls were based on Attribute-Based Access Control (ABAC). As the name implies, ABAC provides access by comparing a rule against attributes, rather than roles. The assigned attributes can be assigned any type of data, including user attributes, objects, environments, and locations.

In the past, to configure a Kubernetes cluster for ABAC, you had to set two values on the API server:

• --authorization-policy-file
• --authorization-mode=ABAC

authorization-policy-file is a local file on the API server. Since it's a local file on each API server, any changes to the file require privileged access to the host and will require you to restart the API server. As you can imagine, the process to update ABAC policies becomes difficult and any immediate changes will require a short outage as the API servers...

What's a Role?

In Kubernetes, a Role is a way to tie together permissions into an object that can be described and configured.

Roles have rules, which are a collection of resources and verbs. Working backward, we have the following:

• Verbs: The actions that can be taken on an API, such as reading (get), writing (create, update, patch, and delete), or listing and watching.
• Resources: Names of APIs to apply the verbs to, such as services, endpoints, and so on. Specific sub-resources may be listed as well. Specific resources can be named to provide very specific permissions on an object.

A Role does not say who can perform the verbs on the resources—that is handled by RoleBindings and ClusterRoleBindings. We will learn more about these in the RoleBindings and ClusterRoleBindings section.

The term "role" can have multiple meanings, and RBAC is often used in other contexts. In the enterprise world, the term "role"...

Mapping enterprise identities to Kubernetes to authorize access to resources

One of the benefits of centralizing authentication is leveraging the enterprise's existing identities instead of having to create new credentials that users that interact with your clusters need to remember. It's important to know how to map your policies to these centralized users. In Chapter 5, Integrating Authentication into Your Cluster, you created a cluster and integrated it with an "enterprise Active Directory." To finish the integration, the following ClusterRoleBinding was created:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ou-cluster-admins
subjects:
- kind: Group
  name: cn=k8s-cluster-admins,ou=Groups,DC=domain,DC=com 
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

This binding allows all users that are members of the cn=k8s-cluster-admins,ou=Groups...

Implementing namespace multi-tenancy

Clusters deployed for multiple stakeholders, or tenants, should be divided up by namespace. This is the boundary that was designed into Kubernetes from the very beginning. When deploying namespaces, there are generally two ClusterRoles that are assigned to users in the namespace:

• admin: This aggregated ClusterRole provides access to every verb and nearly every resource that ships with Kubernetes, making the admin user the ruler of their namespace. The exception to this is any namespace-scoped object that could affect the entire cluster, such as ResourceQuotas.
• edit: Similar to admin, but without the ability to create RBAC Roles or RoleBindings.

It's important to note that the admin ClusterRole can't make changes to the namespace object by itself. Namespaces are cluster-wide resources, so they can only be assigned permissions via a ClusterRoleBinding.

Depending on your strategy for multi-tenancy, the admin...

Kubernetes auditing

The Kubernetes audit log is where you track what is happening in your cluster from an API perspective. It's in JSON format, which makes reading it directly more difficult, but makes it much easier to parse using tools such as Elasticsearch. In Chapter 10, Auditing Using Falco, DevOps AI, and ECK, we will cover how to create a full logging system using the Elasticsearch, Fluentd, and Kibana (EFK) stack.

Creating an audit policy

A policy file is used to control what events are recorded and where to store the logs, which can be a standard log file or a webhook. We have included an example audit policy in the chapter6 directory of the GitHub repository, and we will apply it to the KinD cluster that we have been using throughout the book.

An audit policy is a collection of rules that tell the API server which API calls to log and how. When Kubernetes parses the policy file, all rules are applied in order and only the initial matching policy event will...

Using audit2rbac to debug policies

There is a tool called audit2rbac that can reverse engineer errors in the audit log into RBAC policy objects. In this section, we'll use this tool to generate an RBAC policy after discovering that one of our users can't perform an action they need to be able to do. This is a typical RBAC debugging process and learning how to use this tool can save you hours trying to isolate RBAC issues:

1. In the previous chapter, a generic RBAC policy was created to allow all members of the cn=k8s-cluster-admins,ou=Groups,DC=domain,DC=com group to be administrators in our cluster. If you're logged into OpenUnison, log out.
2. Now, log in again with the username jjackson and the password start123.
3. Next, click on Sign In. Once you're logged in, go to the dashboard. Just as when OpenUnison was first deployed, there won't be any namespaces or other information because the RBAC policy for cluster administrators doesn't...

Summary

This chapter's focus was on RBAC policy creation and debugging. We explored how Kubernetes defines authorization policies and how it applies those policies to enterprise users. We also looked at how these policies can be used to enable multi-tenancy in your cluster. Finally, we enabled the audit log in our KinD cluster and learned how to use the audit2rbac tool to debug RBAC issues.

Using Kubernetes' built-in RBAC policy management objects lets you enable access that's needed for operational and development tasks in your clusters. Knowing how to design policies can help limit the impact of issues, providing the confidence to let users do more on their own.

In the next chapter, Chapter 7, Deploying a Secured Kubernetes Dashboard, we'll be learning about how to secure the Kubernetes dashboard, as well as how to approach security for other infrastructure applications that make up your cluster. You'll learn how to apply what we've learned...

Questions

1. True or false – ABAC is the preferred method of authorizing access to Kubernetes clusters.
   1. True
   2. False
2. What are the three components of a Role?
   1. Subject, noun, and verb
   2. Resource, action, and group
   3. apiGroups, resources, and verbs
   4. Group, resource, and sub-resource
3. Where can you go to look up resource information?
   1. Kubernetes API reference
   2. The library
   3. Tutorials and blog posts
4. How can you reuse Roles across namespaces?
   1. You can't; you need to re-create them.
   2. Define a ClusterRole and reference it in each namespace as a RoleBinding.
   3. Reference the Role in one namespace with the RoleBindings of other namespaces.
   4. None of the above.
5. How should bindings reference users?
   1. Directly, listing every user.
   2. RoleBindings should only reference...