Доступ к Kubernetes

Kubernetes Service Airlock — прокси между пользователями Kubernetes и одним или несколькими кластерами.

При аутентификации пользователь получает kubeconfig для отправки запросов к авторизованным кластерам через Kubernetes Service. Сервис проверяет, изменяет или отклоняет запросы в зависимости от ролей Airlock.

Как это работает

1. Пользователь аутентифицируется в Airlock.
2. Kubernetes Service определяет права по ролям пользователя.
3. Для разрешённых запросов сервис переписывает заголовки для impersonation нужного Kubernetes-пользователя и групп.
4. Запрос передаётся API-серверу Kubernetes.

Поля роли для 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

Определяет, к каким зарегистрированным кластерам Kubernetes пользователь может подключаться. Метки задаются при регистрации агента:

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

kubernetes_resources

Поле версии v6 и выше. Ограничивает доступ к конкретным ресурсам по kind, namespace и name. Имена поддерживают регулярные выражения (с ^ и $).

kubernetes_groups и kubernetes_users

Определяют, от чьего имени пользователь действует в Kubernetes. Группы должны быть связаны с Kubernetes RBAC (ClusterRoleBinding) в целевом кластере.

Пример Kubernetes RBAC в кластере:

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

Пример: ограничение по namespace

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: '*'

Создание роли:

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

Подключение к кластеру

Список доступных кластеров:

airsh kube ls

Аутентификация и обновление kubeconfig:

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

Kubernetes Service фильтрует вывод — пользователь видит только ресурсы, разрешённые его ролью.

Проверка прав:

d8 k auth can-i create pods

Комбинирование Airlock RBAC и Kubernetes RBAC

Airlock RBAC определяет, к каким кластерам и ресурсам пользователь может обращаться. Kubernetes RBAC в целевом кластере определяет, что пользователь может делать с ресурсами (verbs: get, list, create и т.д.).

Рекомендуемый подход:

1. Создайте Kubernetes ClusterRole с нужными правами.
2. Привяжите его к группе, указанной в kubernetes_groups роли Airlock.
3. Ограничьте доступ Airlock через kubernetes_labels и kubernetes_resources.