Kubernetes Policy Action Recommendations

Overview

In QueryPie KAC, administrators can configure access control policies for Kubernetes using YAML-formatted policies. This page aims to offer guidance on Actions to avoid challenges in using client tools such as kubectl, lens, and k9s, which can arise from misconfigured policies.

API Groups Configuration Guide

For commonly used resources like pods, the apiGroup is typically in the core group, represented by an empty string (""). However, for resources like deployments or replicasets, it belongs to the "apps" group, and for ingresses, it belongs to "networking.k8s.io". Managing these settings individually can be challenging for administrators.

While it may be necessary to separate them using apiGroups for resources with identical names, this is not a common scenario.

Therefore, unless you have a specific mission for managing Kubernetes API Groups separately, we generally recommend setting "*" and controlling access permissions through resources.

Resources Configuration Guide

When using 3rd party client tools, monitoring is possible within the allowed scope of resources.

• Resources Section

  • In the above interface, resources are displayed based on the permissions granted to the user.

  • For example, if you only have permissions for pods, you will only see graphs related to pods. If pods are filtered to show only a subset, only that subset will be displayed.

  • This behavior applies similarly to other resources.

  • Recommended Specification

    CODE

    allow:
      actions:
        # If only pods are allowed 
        - apiGroups: ["*"]
          resources: ["pods"]
          namespace: "*"
          name: "*"
          verbs: ["get", "list", "watch"]

• Events Section

  • The events section displays events based on permissions granted for events resources. Similar to the resources section above, it filters based on namespace and name.

  • However, having permissions for pods does not automatically show events related to pods. To view events related to pods, explicit permissions for events resources are required.

  • Events and pods are separate resources. Therefore, even if you have permissions for pods, you must explicitly grant permissions for events resources to view events related to pods.

  • Recommended Specification

    CODE

    allow:
      actions:
        # Allow displaying events along with pods 
        - apiGroups: ["*"]
          resources: ["pods", "events"]
          namespace: "*"
          name: "*"
          verbs: ["get", "list", "watch"]

Verbs Configuration Guide

One of the critical aspects influencing the use of third-party client tools is the configuration of verbs. Administrators specify the scope of resources that users can access through apiGroups, resources, namespace, and name. Verbs determine which APIs users can invoke. Even if the resource scope is correctly set, improper configuration of verb sets can make tool usage difficult.

• View Permissions

  • For users with view-only permissions, they must be granted all three verbs: get, list, watch.

  • While using kubectl with just get and list isn't overly challenging, tools like Lens that support real-time monitoring require the watch verb.

  • Recommended Specification

    CODE

    allow:
      actions:
        - apiGroups: ["*"]
          resources: ["*"]
          namespace: "*"
          name: "*"
          verbs: ["get", "list", "watch"]

• Edit Permissions

  • Users with edit permissions also require view permissions, specifically at least get and list access. This is because kubectl first makes a request to retrieve information before making modification requests for specific resources.

  • In tools like Lens, lacking view permissions means there's no way to access the edit interface.

  • Within the edit permissions, verbs should be grouped according to their roles:

    • Create (create)

    • Modify (patch, update)

    • Delete (delete, deletecollection)

  • While deletecollection isn't commonly used, QueryPie KAC handles deletecollection requests by selecting only resources the user has permission to delete, making it useful.

  • Recommended Specification

    CODE

    allow:
      actions:
        # Create permissions
        - apiGroups: ["*"]
          resources: ["*"]
          namespace: "*"
          name: "*"
          verbs: ["get", "list", "create"]
        # Modify permissions
        - apiGroups: ["*"]
          resources: ["*"]
          namespace: "*"
          name: "*"
          verbs: ["get", "list", "patch", "update"]
        # Delete permissions
        - apiGroups: ["*"]
          resources: ["*"]
          namespace: "*"
          name: "*"
          verbs: ["get", "list", "delete", "deletecollection"]

Additional Recommended Configuration Guides

Example: Restricting Access to Resources in the prod Namespace Environment

allow:
  actions:
    # Allow all actions on resources in the 'dev' namespace
    - apiGroups: ["*"]
      resources: ["*"]
      namespace: "dev"
      name: "*"
      verbs: ["*"]
    # Allow get, list, and watch actions on resources in the 'prod' namespace
    - apiGroups: ["*"]
      resources: ["*"]
      namespace: "prod"
      name: "*"
      verbs: ["get", "list", "watch"]

Example: Restricting Access to Secrets in the prod Namespace

deny:
  actions:
    # Deny all actions on 'secrets' resources in the 'prod' namespace
    - apiGroups: ["*"]
      resources: ["secrets"]
      namespace: "prod"
      name: "*"
      verbs: ["*"]