Risks

Kubernetes offers several main authorization mechanisms to control who can make changes to the cluster via the Kubernetes API. This includes tools like kubectl, system components, and applications that run in the cluster and manipulate its state, such as Jenkins with the Kubernetes plugin or Helm. Among the available authorization mechanisms, Attribute-Based Access Control (ABAC) and Role-Based Access Control (RBAC) are the ones that run locally in a Kubernetes cluster and enable configurable authorization policies. RBAC is preferred due to its ease of management, flexibility, and security advantages.

RBAC vs. ABAC

ABAC (Attribute-Based Access Control)

While ABAC is powerful, it has several drawbacks:

• Complexity: Harder to manage and understand compared to RBAC.
• Security Risks: Requires SSH and root file system access to the master host VM.
• Operational Overhead: The cluster API must be restarted for changes to take effect.

RBAC (Role-Based Access Control)

RBAC is the preferred authorization mechanism due to its simplicity and flexibility:

• Ease of Management: Configurations are done using kubectl or directly via the Kubernetes API.
• Delegation: Users can be authorized to make changes to authorization policies.
• Granularity: Policies can be easily mapped to the resources and operations used in the Kubernetes API.

What Can Be Restricted with RBAC?

RBAC allows restricting actions (verbs) on resources. The following verbs can be used in RBAC policies:

• list: Allows listing resources, e.g., kubectl get pods.
• get: Allows retrieving a specific resource, e.g., kubectl get pod <name>.
• watch: Allows watching for changes to resources, typically used with list or get.
• create: Allows creating new resources.
• delete: Allows deleting resources.
• deletecollection: Allows deleting multiple resources.
• patch: Allows modifying resources.
• update: Allows updating resources using kubectl replace.

Example RBAC Configuration

User-Specific RBAC

In small teams or specific scenarios, each user may get specific rights. However, this approach can lead to complex and hard-to-manage configurations.

Role-Specific RBAC

A more scalable approach is to define roles based on responsibilities and assign these roles to users. This reduces administrative overhead and ensures consistency.

Key Roles and Responsibilities

1. Cluster Admin

   • Responsibilities: Creating the cluster, adding/removing nodes, managing the Control Plane, setting taints, tolerations, node affinities, and ClusterRoles.
   • Role: Use the built-in cluster-admin ClusterRoleBinding.
    

   kubectl get clusterrole cluster-admin kubectl get clusterrolebinding cluster-admin

2. Namespace Creator

   • Responsibilities: Creating namespaces and assigning roles, creating namespace-specific PodSecurityPolicies.
   • Role: Needs all verbs for namespaces and podsecuritypolicies, and roles.
    

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: namespace-creator
   rules:
   - apiGroups: [""]
     resources: ["namespaces", "roles"]
     verbs: ["create", "get", "list", "watch", "delete"]
   - apiGroups: ["policy"]
     resources: ["podsecuritypolicies"]
     verbs: ["create", "get", "list", "watch", "delete"]

    

3. Secret Admin

   • Responsibilities: Managing secrets and PKIs, handling certificate signing requests.
   • Role: Needs access to all secrets and certificate signing requests.
    

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: secret-admin
   rules:
   - apiGroups: [""]
     resources: ["secrets", "certificatesigningrequests"]
     verbs: ["create", "get", "list", "watch", "delete"]

4. Service Manager

   • Responsibilities: Managing specific services within namespaces, ensuring performance and load management.
   • Role: Template role for service-specific responsibilities.

5. Network Admin

   • Responsibilities: Managing network policies, ingress controllers, and troubleshooting network issues.
   • Role: Needs access to networking resources.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: network-admin
   rules:
   - apiGroups: ["networking.k8s.io"]
     resources: ["networkpolicies", "ingresses", "ingressclasses"]
     verbs: ["create", "get", "list", "watch", "delete", "patch", "update"]
   - apiGroups: [""]
     resources: ["pods", "services"]
     verbs: ["get"]

6. Storage Admin

   • Responsibilities: Managing storage resources, troubleshooting storage issues.
   • Role: Needs access to storage resources.
    

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: storage-admin
   rules:
   - apiGroups: ["storage.k8s.io"]
     resources: ["csidrivers", "csinodes", "storageclasses", "volumeattachments"]
     verbs: ["create", "get", "list", "watch", "delete", "patch", "update"]
   - apiGroups: [""]
     resources: ["persistentvolumes"]
     verbs: ["create", "get", "list", "watch", "delete", "patch", "update"]

    

7. Application Manager

   • Responsibilities: Deploying and managing applications, ensuring proper labeling, handling configmaps, secrets, and services.
   • Role: Needs access to application-related resources within namespaces.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: application-deployer
     namespace: <namespace>
   rules:
   - apiGroups: ["apps"]
     resources: ["deployments", "statefulsets", "daemonsets", "replicasets"]
     verbs: ["create", "get", "list", "watch", "delete", "patch", "update"]
   - apiGroups: [""]
     resources: ["configmaps", "persistentvolumeclaims", "pods", "secrets", "services", "serviceaccounts"]
     verbs: ["create", "get", "list", "watch", "delete", "patch", "update"]
   - apiGroups: ["rbac.authorization.k8s.io"]
     resources: ["rolebindings"]
     verbs: ["create", "get", "list", "watch", "delete", "patch", "update"]

8. Read-Only Role (View)

   • Responsibilities: Provides read-only access to view most objects.
   • Role: Useful for superiors, guests, consultants.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: view-access
   subjects:
   - kind: User
     name: <username>
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: view
     apiGroup: rbac.authorization.k8s.io

Conclusion

Implementing a well-defined RBAC policy in Kubernetes ensures that roles and responsibilities are clearly delineated, reducing administrative overhead and enhancing security. By following the role-specific RBAC approach, you can efficiently manage access controls, delegate responsibilities, and maintain a secure and well-organized cluster. Regularly review and update these policies to adapt to the evolving needs of your organization and ensure compliance with security best practices.