Авторизация

Аутентификация и авторизация

Airlock выполняет и аутентификацию, и авторизацию:

• Аутентификация — подтверждение личности пользователя или сервиса.
• Авторизация — проверка прав доступа к ресурсу.

В этом документе описана авторизация пользователей и сервисов на основе RBAC.

Пользователи и роли

Airlock поддерживает несколько типов учётных записей:

• Интерактивные и неинтерактивные.
• Локальные и внешние.

После успешной аутентификации каждому пользователю назначается одна или несколько ролей.

Интерактивные пользователи

Интерактивные пользователи могут быть локальными или внешними. Локальные учётные записи хранят хеш пароля и данные MFA в бэкенде Airlock. Внешние учётные записи аутентифицируются через провайдер идентификации по протоколам SSO — OAuth 2.0, OIDC или SAML.

Внешние пользователи из SSO

При каждом входе пользователя SSO Airlock создаёт временную запись учётной записи, которая автоматически истекает вместе с SSO-сессией, и записывает события в журнал аудита. Это предотвращает конфликты имён с локальными пользователями.

Внешние пользователи из других кластеров

Пользователь может быть внешним по отношению к кластеру Airlock, если другой кластер или CA выдаёт сертификат, которому доверяет этот кластер. В этом случае Airlock применяет логику сопоставления ролей доверенных кластеров.

Локальные интерактивные пользователи

Локальные интерактивные пользователи имеют запись в бэкенде Airlock с учётными данными. Администратор создаёт учётные записи через airctl users add или API.

Каждый локальный пользователь Airlock должен быть связан с одной или несколькими ролями — это называется «сопоставлением ролей».

Неинтерактивные пользователи

Airlock поддерживает неинтерактивных пользователей для сервисов автоматизации (например, CI/CD или микросервисов). Локальные неинтерактивные пользователи имеют запись, сопоставляющую имя с ролями, но без учётных данных в базе данных.

Ролевое управление доступом (RBAC)

Каждому пользователю Airlock назначается одна или несколько ролей, которые определяют доступ к ресурсам и API Airlock.

Правила allow и deny

Каждая роль содержит два списка правил: allow и deny:

• По умолчанию всё запрещено.
• Правила deny проверяются первыми и имеют приоритет.
• Правило состоит из ресурсов и глаголов (verbs).

Пример правила allow для просмотра списка записанных SSH- или Kubernetes-сессий:

allow:
  - resources: [session]
    verbs: [list]

Principals

Роли определяют, какие principals (например, пользователи ОС Linux или группы Kubernetes) могут использовать пользователи с этой ролью:

spec:
  allow:
    logins: [ubuntu]
    kubernetes_groups: [viewer]

Если у пользователя несколько ролей, списки principals объединяются.

Метки

Метки ролей определяют, к каким ресурсам применяются правила. Пример доступа к SSH-узлам и кластерам Kubernetes:

spec:
  allow:
    node_labels:
      'environment': '^test|staging$'
    kubernetes_labels:
      'region': 'us-west-*'
      'cluster_name': '^us.*\.example\.com$'

Правила применения меток:

• Для совпадения правила allow должны совпасть все метки в правиле.
• Для совпадения правила deny достаточно совпадения любой метки.

Пример: пользователь Alice имеет роли dev и prod. Роль dev разрешает SSH как root и полный доступ к Kubernetes как system:masters для ресурсов с метками test или stage. Роль prod разрешает SSH как ubuntu и доступ к Kubernetes как view для ресурсов с меткой prod.

• Alice может подключиться по SSH как root к серверу с меткой test или stage.
• Alice не может подключиться как root к серверу с меткой prod — роль prod разрешает только ubuntu.

Шаблоны ролей

Роли поддерживают переменные шаблонов:

spec:
  allow:
    logins: ['{{internal.logins}}']
    kubernetes_groups: ['{{external.groups}}']

Любая роль с интерполяцией переменных считается шаблоном роли.

Правила интерполяции:

• Если external.groups — список ["dev", "prod"], выражение ["{{external.groups}}"] интерполируется в ["dev", "prod"].
• Если переменная отсутствует, выражение "{{external.groups}}" даёт пустую строку.
• Недопустимые значения (например, -foo как Unix-логин) опускаются.

Шаблоны ролей вычисляются в момент доступа к ресурсу прокси или узлом. Переменные из провайдера идентификации кодируются в расширениях X.509-сертификата.

Условия ролей

Поле where ограничивает доступ по условиям. Пример — доступ только к собственным сессиям:

kind: role
metadata:
  name: only-own-sessions
spec:
  allow:
    rules:
    - resources: [session]
      verbs: [list, read]
      where: contains(session.participants, user.metadata.name)

Параметры ролей

Помимо правил allow и deny, роли задают параметры подключения:

kind: role
version: v5
metadata:
  name: relaxed
spec:
  options:
    max_session_ttl: 8h
    lock: strict

При конфликте параметров из нескольких ролей Airlock выбирает наиболее строгое значение (например, меньший max_session_ttl или режим strict вместо best_effort).

Запросы доступа (Access Requests)

Роли могут разрешать запрос повышенных привилегий — других ролей или отдельных ресурсов. Роли определяют, кто может рассматривать запросы, и сколько одобрений или отклонений требуется. В Airlock эта возможность доступна через веб-интерфейс, airsh и предустановленные роли requester и reviewer.

spec:
  allow:
    review_requests:
      roles: ['dbadmin']
    request:
      roles: ['common', 'dev-*']
      thresholds:
        - approve: 2
          deny: 1

Дополнительные ресурсы