Access to Kubernetes

The Airlock Kubernetes Service acts as a proxy between Kubernetes users and one or more clusters.

Upon authentication, a user receives a kubeconfig for sending requests to authorized clusters through the Kubernetes Service. The service checks, modifies, or rejects requests based on the user’s Airlock roles.

How it works

1. The user authenticates with Airlock.
2. The Kubernetes Service determines permissions from the user’s roles.
3. For allowed requests, the service rewrites headers to impersonate the appropriate Kubernetes user and groups.
4. The request is forwarded to the Kubernetes API server.

Role fields for Kubernetes

kind: role
version: v6
metadata:
  name: kube-access
spec:
  allow:
    kubernetes_labels:
      'region': '*'
      'platform': 'production'
    kubernetes_resources:
      - kind: pod
        namespace: "production"
        name: "^webapp-[a-z0-9-]+$"
      - kind: pod
        namespace: "development"
        name: "*"
    kubernetes_groups:
    - developers
    kubernetes_users:
    - admin
  deny: {}

kubernetes_labels

Defines which registered Kubernetes clusters the user can connect to. Labels are set when registering the agent:

--set labels.region=local --set labels.platform=production

kubernetes_resources

Available in v6 and above. Restricts access to specific resources by kind, namespace, and name. Names support regular expressions (using ^ and $).

kubernetes_groups and kubernetes_users

Define which Kubernetes identity the user acts as. Groups must be bound via Kubernetes RBAC (ClusterRoleBinding) in the target cluster.

Example Kubernetes RBAC in a cluster:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-viewer
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-viewer
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-viewer
  apiGroup: rbac.authorization.k8s.io

Example: namespace restriction

kind: role
version: v6
metadata:
  name: dev-kube
spec:
  allow:
    kubernetes_labels:
      'env': 'dev'
    kubernetes_resources:
      - kind: pod
        namespace: "development"
        name: "*"
      - kind: deployment
        namespace: "development"
        name: "*"
    kubernetes_groups:
    - developers
    kubernetes_users:
    - dev-user
  deny:
    kubernetes_resources:
      - kind: '*'
        namespace: 'production'
        name: '*'

Create the role:

airctl create -f dev-kube.yaml
airctl users update developer --set-roles=access,dev-kube

Connecting to a cluster

List available clusters:

airsh kube ls

Authenticate and update kubeconfig:

airsh kube login my-cluster
d8 k get pods --all-namespaces

The Kubernetes Service filters the output — a user sees only resources permitted by their role.

Check permissions:

d8 k auth can-i create pods

Combining Airlock RBAC and Kubernetes RBAC

Airlock RBAC determines which clusters and resources a user can access. Kubernetes RBAC in the target cluster determines what the user can do with those resources (verbs: get, list, create, etc.).

Recommended approach:

1. Create a Kubernetes ClusterRole with the required permissions.
2. Bind it to the group specified in kubernetes_groups of the Airlock role.
3. Restrict Airlock access via kubernetes_labels and kubernetes_resources.