Kubernetes Policy Action Configuration Reference Guide

Overview

In QueryPie KAC, you configure access control policies for k8s using YAML-based policies. This guide provides guidance on Actions to prevent difficulties when using client tools such as kubectl, Lens, and k9s due to misconfigured policies.

API Groups Configuration Guide

For commonly used resources like pods, the apiGroups is the core group so it is an empty string "", but for deployments and replicasets it is "apps", and for ingresses it is "networking.k8s.io", making it difficult for administrators to know and configure each one individually.

Of course, if resources share the same resource name, you may need to separate them via apiGroups, but this is not a common situation.

Therefore, unless you have a specific mission to manage Kubernetes API Groups, it is generally recommended to set apiGroups to "*" and control access permissions through resources.

Resources Configuration Guide

When using 3rd Party Client Tools, you can monitor the status within the scope of permitted resources.

• Resources Section
  • In the screen above, resources are displayed only for the resources you have permissions for.
  • So if you only have permissions for pods, only the graph for pods is shown, and if pods are filtered so that only some are visible, only those are displayed.
  • Other resources work the same way.
  • Recommended spec

    allow:
      actions:
        # When allowing only Pods
        - apiGroups: ["*"]
          resources: ["pods"]
          namespace: "*"
          name: "*"
          verbs: ["get", "list", "watch"]

• Events Section
  • The events section below is displayed based on permissions for the events resource, and like the resources section above, it is filtered by namespace and name.
  • However, having permissions for pods does not mean that pods-related events are displayed, so to view this screen, you must explicitly grant permissions for the events resource.
  • The events resource and pods resource are separate resources. Therefore, even if you grant only pods permissions while having events resource permissions, it does not mean that only events related to pods will be retrieved.
  • Recommended spec

    allow:
      actions:
        # When allowing Events output together
        - apiGroups: ["*"]
          resources: ["pods", "events"]
          namespace: "*"
          name: "*"
          verbs: ["get", "list", "watch"]

Verbs Configuration Guide

The part most affected when using 3rd Party Client Tools is verbs. Administrators specify the scope of resources users can access through apiGroups, resources, namespace, and name, and specify which APIs can be called through verbs. Even if the resource scope is configured well, if the verb groupings are not properly configured, tool usage becomes difficult.

• View Permissions
  • For users who only receive View permissions, you must grant get, list, and watch all together.
  • Using kubectl is not too difficult with just get and list, but without watch, tools like Lens that support live monitoring become difficult to use.
  • Recommended spec

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

• Edit Permissions
  • For users who also receive Edit permissions, you must also grant View permissions (at minimum get and list). This is because even in kubectl, when a modification request is made for a specific resource, a read request is made first.
  • In tools like Lens, without View permissions there is no way to navigate to the Edit screen.
  • Among Edit operations, they should be grouped by role: create (create), modify (patch, update), and delete (delete, deletecollection).
  • Although deletecollection is not commonly used, in KAC, even when a deletecollection request is received, only resources for which the user has permissions are selected and deleted, so it can be useful.
  • Recommended spec

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

Other Recommended Configuration Guide

Example) Restricting permissions for resources in the prod namespace

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

Example) Restricting secret access in the prod namespace

deny:
  actions:
    - apiGroups: ["*"]
      resources: ["secrets"]
      namespace: "prod"
      name: "*"
      verbs: ["*"]