Airlock использует ролевую модель доступа (RBAC). Роль содержит два списка правил: allow и deny.
- По умолчанию доступ запрещён.
- Правила
denyпроверяются первыми и имеют приоритет.
Роли и другие динамические ресурсы управляются через веб-интерфейс Airlock, утилиту airctl или API.
Просмотр ролей
airsh login --user=admin --proxy=airlock.example.com
airctl get rolesПредустановленные роли
| Роль | Описание |
|---|---|
access | Доступ к ресурсам кластера |
editor | Редактирование настроек конфигурации кластера |
auditor | Чтение событий, аудит-логов и воспроизведение сессий |
requester | Создание запросов на доступ (Access Requests) |
reviewer | Рассмотрение и одобрение запросов на доступ |
Версии ролей
Поддерживаются версии v3–v7. Версии v4 и выше обратно совместимы с v3; отличие — значения по умолчанию для незаданных полей.
| Метка | По умолчанию v3 | По умолчанию v4+ |
|---|---|---|
node_labels | [{"*": "*"}] при наличии logins, иначе [] | [] |
app_labels | [{"*": "*"}] | [] |
kubernetes_labels | [{"*": "*"}] | [] |
db_labels | [{"*": "*"}] | [] |
Версия v6 добавила поле kubernetes_resources для детального контроля ресурсов Kubernetes.
RBAC для инфраструктурных ресурсов
Роль определяет, к каким ресурсам (приложения, серверы, базы данных) пользователь имеет доступ. Механизм: метки на ресурсах + правила allow/deny в роли.
Пример: инфраструктура разделена метками environment=production и environment=staging. Роль стажёра может разрешать доступ только к environment=staging.
Пример роли с метками
kind: role
version: v5
metadata:
name: example-role
spec:
allow:
node_labels:
'env': 'stage'
deny:
node_labels:
'workload': ['database', 'backup']Несколько меток в одном правиле интерпретируются как логическое «И»:
db_labels:
'env': 'prod'
'region': ['eu-central-1', 'eu-west-1']Расширенный синтаксис меток
kind: role
version: v5
metadata:
name: example-role
spec:
allow:
node_labels:
'environment': 'test'
'*': '*'
'environment': ['test', 'staging']
'environment': '^test|staging$'Опции роли
Опции ограничивают параметры сессий. При нескольких ролях применяются комбинированные правила:
| Опция | Описание | Поведение при нескольких ролях |
|---|---|---|
max_session_ttl | Максимальный TTL SSH-сертификата | Минимальный TTL |
forward_agent | SSH agent forwarding | Логическое «ИЛИ» |
port_forwarding | TCP port forwarding | Логическое «ИЛИ» |
ssh_file_copy | SCP/SFTP | Логическое «И» |
client_idle_timeout | Завершение неактивных сессий | Минимальное значение |
require_session_mfa | MFA на каждую сессию | Логическое «ИЛИ» |
pin_source_ip | Привязка к IP источника | Логическое «ИЛИ» |
Создание роли
airctl create -f my-role.yaml
airctl get roles --format textНазначение роли пользователю:
airctl users update alice --set-roles=access,my-roleРазделы документации
- SSH-хосты — логины, метки узлов, опции SSH-сессий
- Kubernetes — кластеры, группы, пользователи и ресурсы Kubernetes
- Базы данных — метки БД, учётные записи и имена баз