Skip to Content
Administrator ManualKubernetesK8s Access ControlPoliciesKubernetes Policy YAML Code Syntax Guide

Kubernetes Policy YAML Code Syntax Guide

This document is written based on QueryPie Enterprise 9.20.0.

QueryPie Access Control Policy Overview

Access control policies defined in QueryPie operate based on EABAC (Enhanced Attribute Based Access Control). EABAC is a policy control method that enables access control and permission management for resources registered in QueryPie based on the roles (Role) and attributes (Attribute) of QueryPie users. It provides more flexible and sophisticated access control by combining the features of RBAC (Role-Based Access Control) and ABAC (Attribute-Based Access Control). All policies operate on the premise of All Deny.

EABAC operates with two components: Role and Policy. Role settings are configured through GUI, and Policy definitions are managed through code (YAML).

For Kubernetes policies, the specification was designed as a comprehensive model that can accommodate both Roles limited to namespaces that actually exist in Kubernetes and ClusterRoles that support resources outside the namespace scope.

Kubernetes Policy YAML Basic Structure

Wildcard (”*”) and regular expression (RE2 format : ^$ must be explicitly specified) patterns are supported in general policy code except for some items.

Category

Property

Required

Description

Valid Values

apiVersion

-

O

The version of the written YAML Code. This is a system-managed value and does not need to be modified.

kubernetes.rbac.querypie.com/v1

kind

-

O

The type of the written YAML Code. This is a system-managed value and does not need to be modified.

KacPolicy

spec:
<effect>

-

O

Specifies whether to allow or deny specific rules of the policy.

  • Each policy only allows the following specs:
    • Single Allow
    • Single Deny
    • Single Allow & Single Deny
  • Deny has higher priority than Allow.

allow, deny

resources

O

Specifies resources to allow/deny access. Wildcard and Regular Expression Allowed

- "cluster:*" - "cluster:^eks-.*$"

subjects

O

Specifies Kubernetes users/groups to impersonate Kubernetes commands.

  • kubernetesGroups : Specifies the kubernetes group to be used by QueryPie Proxy.
  • impersonation : Specifies target users/groups to allow impersonation at the client side. Wildcard Allowed

kubernetesGroups:
- "system:masters"
- $user.groups impersonation:
users:
- "system:user"
groups:
- "system:admin"

actions

O

Specifies the Resource APIs to allow/deny within the Kubernetes cluster API server. Wildcard and Regular Expression Allowed

  • apiGroups : Defines the Kubernetes API group list. Wildcard Allowed
  • resources : Defines Kubernetes resources. Wildcard Allowed
  • namespace : Defines the target namespace. Wildcard and Regular Expression Allowed
  • name : Defines the target resource name. Wildcard and Regular Expression Allowed
  • verbs : Specifies permissions within kubernetes to allow or deny operations. Wildcard Allowed

- apiGroups: ["*"]
resources:
- "*"
namespace: "*"
name: "*"
verbs: ["*"]

conditions

Controls the target in detail by applying conditions for whether to apply resource access policies.

  • resourceTags : Can filter by resource tag keys and values. Value Wildcard and Regular Expression Allowed
  • userAttributes : Restricts permission usage by using user attributes as conditions. Value Wildcard and Regular Expression Allowed
  • ipAddresses : Defines IP access control condition lists for resources in single IP, CIDR format. Wildcard Allowed

resourceTags:
- "Owner": "Daniel"
userAttributes:
- "department": "DevOps" ipAddresses:
- "10.10.10.0/24"

How to Specify Resources

resources defines not Kubernetes resources but resources for Kubernetes clusters registered in QueryPie.

  1. Definition of the resources field is required. required
  2. Enter based on the Kubernetes cluster name.
    • "cluster:{Kubernetes Cluster Name in QueryPie}"
  3. Kubernetes cluster names are established based on the following criteria.
    • Character length limit of 100 characters
    • Only alphabetic characters (case-sensitive), numbers, and the following special symbols are allowed
      • underscore (_)
      • hyphen (-)
    • Names must start and end with alphabetic characters or numbers
    • Cluster names must not be duplicated
  4. Multiple Kubernetes clusters can be specified in a single policy.
    • - "cluster:kubepie-dev-1"
      - "cluster:kubepie-dev-2"
    • ["cluster:kubepie-dev-1", "cluster:kubepie-dev-2"]
  5. Paths allow wildcards.
    • "cluster:kubepie-dev-*"
  6. Paths allow regular expressions.
    • "cluster:^kubepie-dev-.*$"

How to Specify Subjects

subjects defines users/groups within Kubernetes to impersonate Kubernetes commands. subjects is a field that needs to be applied only in spec:allow, and is not syntactically allowed in spec:deny.

  1. kubernetesGroups: required
    • Defines the kubernetes group account that QueryPie Proxy will impersonate to perform APIs on resources.
      • These subjects must be definable at the Policy-wide level and must be defined so that at least one is assigned.
        • These subjects for Impersonation can overlap with other Policies within a single Role.
      • Defines kubernetes-side groups (single or multiple) that can perform permissions on resources specified in Resources.
        kubernetesGroups: - system:masters - default-group-account
      • In kubernetesGroups, QueryPie User’s Group can be entered in reserved word format. In this case, the User’s Group must be entered without double quotes (”), and when users view the Policy, the actual user Group values are displayed.
        kubernetesGroups: - $user.groups
  2. impersonation: OPTIONAL
    • When users attempt impersonation (—as, —as-group) in kubectl commands with permissions of specific serviceaccounts, etc. within kubernetes from the client side, this defines the allowed call list.
      • users: Lists values allowed for the “—as” parameter as users/service accounts existing within Kubernetes.
      • groups: Lists values allowed for the “—as-group” parameter as group accounts existing within Kubernetes.
        impersonation: users: - "system:serviceaccount:argocd" groups: - "system:admin"
      • Wildcards are allowed. ("*")

How to Specify Actions

Specifies the Resource API list to allow within the cluster API server. Each action requires apiGroups, resources, namespace, name, verbs entries.

  1. apiGroups : Defines the Kubernetes API group list.
    1. By defining API groups, more detailed permission control is possible for each API group.
    2. When control over custom resources is needed, it can be specified in apiGroups to control only custom resources.
    3. Reference:
      1. API Groups Guide  
      2. API Group List 
    4. Wildcards are allowed to comprehensively specify all API groups.
      • apiGroups: ["*"]
  2. resources : Defines the Kubernetes resource list.
    1. Commonly used resources are as follows:
      • pods, pods/exec, pods/log, pods/portforward, services, ingresses, deployments, replicasets, statefulsets, daemonsets, configmaps, secrets, namespaces, nodes, persistentvolumes, persistentvolumeclaims, jobs, cronjobs, serviceaccounts, endpoints, roles, rolebindings, clusterroles, clusterrolebindings
    2. Resources not listed above can also be accepted in policies.
    3. Even if you grant permissions only to namespace sub-resources, ReadOnly permissions for Namespace are also granted. Therefore, cases where you need to specify the namespace every time when calling resources do not occur. If you want to prevent granting permissions to specific namespaces, you can set access denial for namespace resources in spec:deny.
    4. Multiple resources can be specified in a single policy action.
    resources: - "pods" - "deployments" - "configmaps"
    1. Wildcards are allowed. ("*")
  3. namespace : Defines the target namespace.
    1. By defining namespaces in actions, you can control allowed target namespaces within the cluster for each resource.
    2. Both wildcards and regular expressions are allowed.
      • namespace: "*"
    3. For resources that do not belong to namespaces other than namespaces, you do not need to write the namespace.
      1. Examples) persistentvolumes, persistentvolumeclaims, serviceaccounts, customresourcedefinitions, endpoints, nodes, clusterroles, clusterrolebindings, etc.
  4. name : By defining target resource names, you can control based on naming among allowed resources within the cluster.
    1. Both wildcards and regular expressions are allowed.
      • name: "pods-*"
  5. verbs : Specifies API permissions within kubernetes to allow or deny operations.
    • Commonly called verbs are as follows:
      • get: Resource information retrieval
      • list: Resource list enumeration
      • watch: Resource change monitoring
      • create: New resource creation
      • update: Existing resource update
      • patch: Resource partial modification
      • delete: Resource deletion
      • deletecollection: Multiple resource deletion in a single operation
    • Even if there are special verbs not listed above, they can be specified and applied in policies.
    • When supporting 3rd-Party clients, the following verbs are required:
      • View permissions : get, list, watch
      • Edit permissions : get, list, watch + create, update, patch, delete, deletecollection
    • Generally, specifying the create verb is required for creating container shell access sessions through pod exec commands.
    • Wildcards are allowed.
      • verbs: ["*"]

How to Specify Conditions

The conditions item can define resourceTags, userAttributes, and ipAddresses as conditions. OPTIONAL

  • resourceTags : In tag items, you can filter by resource tag keys and values.
    resourceTags: "region": "ap-northeast-1" "Owner": "Brant"
  • userAttributes : Specifies user attributes as conditions and restricts the use of permissions defined in the policy only to users whose values match.
    userAttributes: "countryCode": "KR" "department": "Infra"
  • ipAddresses : Defines IP access control condition lists for resources in single IP, CIDR format.
    ipAddresses: ["10.10.0.0/24", "10.11.10.1"]

KAC Policy Example

apiVersion: kubernetes.rbac.querypie.com/v1 kind: KacPolicy spec: allow: resources: - "cluster:*" subjects: kubernetesGroups: - "system:masters" impersonation: users: ["system:serviceaccount:argocd"] groups: ["system:admin"] actions: - apiGroups: ["*"] resources: - "pods" namespace: "*" name: "*" verbs: ["get", "list", "watch"] conditions: resourceTags: "Owner": ["Kenny", "Brant"] "Team": "DevSecOps" userAttributes: "countryCode": "KR" "department": "Infra" ipAddresses: ["10.10.0.0/24", "10.11.10.1"] deny: resources: - "cluster:kubepie-*" actions: - apiGroups: ["*"] resources: - "*" namespace: "production" name: "*" verbs: ["*"] conditions: resourceTags: "Owner": "Brant"
Last updated on