Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "what is the method of auditing Kubernetes RBAC strategy". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Authentication and authorization are very important to any security system, and Kubernetes is no exception. Even if we are not security workers, we need to know if our Kubernetes cluster has sufficient access control permissions. The Kubernetes community is also increasingly concerned about container security assessment (including penetration testing, configuration auditing, simulated attacks). If you are an application security engineer or a security-aware DevOps engineer, it is best to understand Kubernetes's authorization model.

The authorization control principle of Kubernetes is the same as that of most systems: the principle of minimum authorization is used when granting access. For example, if a Pod uses a specific serviceAccount, the Pod is limited to have only the specified permissions and access to specific resources.

Kubernetes supports role-based access control (Role-Based Access,RBAC) since 1.6. cluster administrators can control resource access to users or service accounts more precisely. Let's briefly review the principle of RBAC.

1. Basic concepts of RBAC

The RBAC authorization policy creates a series of Role and ClusterRole to bind the corresponding resource entities (serviceAccount or group) to restrict their operations on the cluster. Each Role is built on the Create, Read, Update, Delete (CRUD) model and uses verbs to apply the appropriate permissions. For example, the verb get means to be able to get the details of a particular resource. If you want to gain access to Secrets, you can create the following ClusterRole:

ApiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: secret-readerrules:- apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"]

For more detailed documentation on RBAC, please refer to the Kubernetes official documentation or CNCF's blog.

2. RBAC practice

The RBAC authorization model provides us with a precise access control mechanism, but as the environment becomes more complex, these RBAC configurations become more and more difficult to maintain. The RBAC configuration may include Roles, RoleBindings, ClusterRoles, ClusterRoleBindings, ServiceAccounts, Groups, and so on, and it is difficult to track the relationship between them.

Take Chestnut as an example, first create a ServiceAccount called helm, then create a corresponding Role binding "tiller-world" namespace, which only has the permission of list pods, and finally bind the Role to the previously created ServiceAccount by creating a RoleBinding.

ApiVersion: v1kind: ServiceAccountmetadata: name: helm namespace: helm-world---apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: name: tiller-user namespace: tiller-worldrules:- apiGroups:-"" resources:-pods/portforward verbs:-create- apiGroups:-"" resources:-pods verbs:-list---apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: name: tiller-user-binding namespace: tiller-worldroleRef: apiGroup: rbac. Authorization.k8s.io kind: Role name: tiller-usersubjects:- kind: ServiceAccount name: helm namespace: helm-world

If you want to know whether newly created authorized objects are granted only the necessary access, you need to review these objects and their relationships in the cluster. Sometimes you also need to ensure that it only has access to specific resource instances and does not allow access to all resource instances. For example, if you do not want the above ServiceAccount to access all Secret, but only allow it to access a specific Secret, you can use the resourceNames field to specify:

Rules:- apiGroups: ["] resources: [" secrets "] resourceNames: [" my-pod-secrets "] verbs: [" get "," watch "," list "]

The problem with this approach is that resources that do not exist in the cluster cannot be filtered, which means that if the name of the resource is dynamic, the corresponding Role cannot be created unless the resource is created at the same time as the Role is created.

3. Audit is very important.

In order to see what each Role does and what each resource object should be able to do, we have to do some auditing. The simplest audit is to confirm whether a Service Account has the permission of Cluster Admin, and more complicated, to confirm whether a certain CI/CD Service Account has the permission of Update Pod within the specified namespace.

Based on the goal of audit, it can be roughly divided into two audit modes:

Resource auditing: identify the riskiest resource objects and see who can access them.

Account audit: check the effective permissions of accounts and make sure they are reasonable.

Account audits are thorough but time-consuming; resource audits can identify problems more quickly, but there may be omissions. For example:

Resource audit: see who can access a Secret resource and ensure that it follows the principle of minimum authorization.

Account auditing: traverse all user,group,Service Account and RoleBinding to ensure that they are granted the correct access and are limited to a specific namespace.

Here are several command-line tools to help you audit RBAC more easily.

4. Kubectl Can-I

Some production environments do not allow the installation of additional services and can only use kubectl, and we can use kubectl's built-in command kubectl auth can-i to view RBAC permissions.

For example, check to see if you have permission to get pod:

$kubectl auth can-i get podsyes

Check to see if you have access to cluster-admin:

$kubectl auth can-i "*" * yes

List all the permissions you have in a namesapce:

$kubectl auth can-i-- list-- namespace=secureResources Non-Resource URLs Resource Names Verbs*.* [] [] [*] [*] [] [*] selfsubjectaccessreviews.authorization.k8s.io [] [] [create] selfsubjectrulesreviews.authorization.k8s.io [] [] [create] [/ api/*] [] [get] [/ api] [] [get] [/ apis/*] [] [get] [/ apis] [] [get] [/ healthz] [] [get] [/ healthz] [] [get] [/ openapi/*] [] [get] [/ openapi] [] [get] [/ version/] [] [get] [/ version/] [] [get] [/ version] [] [get] [/ version] [] [get]

To make it a little more interesting, we can also use Kubernetes's Impersonation API to see if other accounts have access to specific resources. For example, check to see if the Service Account named unprivileged-service-account has permissions for get pod:

$kubectl auth can-i get pod\-- as system:serviceaccount:secure:unprivileged-service-accountyes

The-- as parameter is used to specify the account name, and a similar parameter is-- as-group, which is actually a set of request headers passed to API Server.

In addition to Service Account, there will also be User in Kubernetes. Every time a Service Account is created, a corresponding User is automatically created with the name format: system:serviceaccount:. If you want to know the username of a Service Account, you can calculate it from its yaml file:

$kubectl get serviceaccount unprivileged-service-account- o yamlapiVersion: v1kind: ServiceAccountmetadata: creationTimestamp: "2019-07-23T17:44:31Z" name: unprivileged-service-account namespace: default resourceVersion: "98089" selfLink: / api/v1/namespaces/default/serviceaccounts/unprivileged-service-accountsecrets:- name: unprivileged-service-account-token-9cggz

By specifying the value of the verbs field as impersonate, you can give one user the permissions of another user, that is, you can impersonate other users. For example, administrators can use this feature to debug authorization policies by temporarily impersonating other users and seeing if requests are denied.

For example, if you want a non-Cluster Admin account to impersonate other users, you can create a ClusterRole like this:

ApiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: impersonatorrules:- apiGroups: [""] resources: ["users", "groups", "serviceaccounts"] verbs: ["impersonate"] 5. Kubectl Who Can

The tool described below is a plug-in for kubectl called who-can, which, as its name implies, shows which accounts have access to specific resources. The installation method is simple and can be installed through kubectl's plug-in management framework Krew:

Install krew. Reference https://github.com/kubernetes-sigs/krew/

Install who-can:

$kubectl krew install who-can

Suppose there is a Secret in secure namespace named cluster-admin-creds, and you want to see who has access to it:

$kubectl who-can get secret cluster-admin-creds-n secureROLEBINDING NAMESPACE SUBJECT TYPE SA-NAMESPACEunpriv_sa_binding secure unprivileged-service-account ServiceAccount secureCLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACEcluster-admin system:masters Group

The output information is also very clear at a glance, there is nothing to say. As a reminder, the tool only supports viewing create, update, and delete access, not use. Use is used to bind the Pod Security Policy to the corresponding Role.

6. Rakkess

Rakkess is similar to who-can in that it can list the access permissions of an account to all resources and can be installed through krew.

The method is also simple. If you want to see the current user's access to all resources, you can use the following command:

If you want to see the access permissions of a particular Service Account to all resources, you can use the following command:

$kubectl access-matrix-- as system:serviceaccount:kube-ovn:ovn-n kube-ovn

You can refer to the official documentation for more use cases.

7. RBack

Rback is used to visually display the output of kubectl, which can be output in .dot format, .png or any format.

For example:

$kubectl get sa,roles,rolebindings\-n monitoring-o json | rback > rback.dot

Or save as png:

$kubectl get sa,roles,rolebindings\-n monitoring-o json\ | rback | dot-Tpng > rback.png

8. RBAC-View

Rbac-view can also be used to visualize the relationship between accounts and permissions, but unlike rback, it is a web application, and the installation method is based on the official documentation.

Mode of use:

$kubectl rbac-viewserving RBAC View and http://localhost:8800

Open the link http://localhost:8800 in the browser.

9. Ultimate test

All the methods mentioned above can help us collect information quickly, but sometimes false positives are inevitable. To confirm whether an account has the appropriate permissions, you can use the ultimate method mentioned below. For example, to confirm that unprivileged-service-account in secure namespace has get secret permissions, you can use the following command:

$kubectl get secrets\-as system:serviceaccount:secure:unprivileged-service-account\-o yaml10. Simulated attack

The best way to prevent an attack is to simulate an attack, and we can simulate a hacker to enter one of the Pod to see if we can perform some indescribable operations. The steps are as follows:

Create a Service Account.

$kubectl create serviceaccount ncc-sa

Create the appropriate role.

Bind Role to Service Account.

Create a test Pod,serviceAccountName specified as ncc-sa.

Enter the Pod

Verify that you have permissions for get pod.

This is the end of the content of $kubectl get pod, "what is the method of auditing Kubernetes RBAC policies". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.