Механизм секретов Kubernetes

Этот механизм может использовать внешние сертификаты X.509 в рамках TLS или для проверки подписи. Проверка подписей с использованием сертификатов X.509, использующих SHA-1, не поддерживается без обходных решений. См. FAQ по устареванию для получения дополнительной информации.

Механизм секретов Kubernetes в StarVault генерирует токены сервисных аккаунтов Kubernetes, а также, при необходимости, создает сервисные аккаунты, привязки ролей и роли. Сгенерированные токены сервисных аккаунтов имеют настраиваемое время жизни (TTL), а все созданные объекты автоматически удаляются при истечении срока аренды (lease) в StarVault.

Для каждой аренды StarVault создает токен сервисного аккаунта, привязанный к указанному сервисному аккаунту. Этот токен возвращается вызывающему.

Чтобы узнать больше о сервисных аккаунтах в Kubernetes, ознакомьтесь с документацией по сервисным аккаунтам Kubernetes и документацией по RBAC в Kubernetes.

Не рекомендуется использовать токены, созданные механизмом секретов Kubernetes, для аутентификации через метод Kubernetes Auth в StarVault. Это приведет к созданию множества уникальных идентичностей в StarVault, что усложнит их управление.

1. Настройка

Механизм секретов Kubernetes необходимо предварительно настроить, прежде чем он сможет выполнять свои функции. Эти действия обычно выполняются оператором или системой управления конфигурацией.

По умолчанию StarVault подключается к Kubernetes, используя собственный сервисный аккаунт. Если используется стандартная Helm-диаграмма, этот сервисный аккаунт создаётся автоматически и носит имя, соответствующее релизу Helm (обычно starvault, но его можно изменить с помощью значения Helm-параметра server.serviceAccount.name).

Необходимо убедиться, что сервисный аккаунт, который использует StarVault, имеет права для управления токенами сервисных аккаунтов, а также (опционально) для управления самими сервисными аккаунтами, ролями и привязками ролей. Эти разрешения можно задать через Kubernetes Role или ClusterRole. Роль связывается с сервисным аккаунтом StarVault с помощью RoleBinding или ClusterRoleBinding.

Пример минимальной ClusterRole для создания токенов сервисных аккаунтов:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: k8s-minimal-secrets-abilities
rules:
- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  verbs: ["create"]

Также можно создать более расширенную роль с полными правами на управление токенами, аккаунтами, привязками и ролями:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: k8s-full-secrets-abilities
rules:
- apiGroups: [""]
  resources: ["serviceaccounts", "serviceaccounts/token"]
  verbs: ["create", "update", "delete"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings", "clusterrolebindings"]
  verbs: ["create", "update", "delete"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles", "clusterroles"]
  verbs: ["bind", "escalate", "create", "update", "delete"]

Создайте эту роль в Kubernetes, например, с помощью kubectl apply -f.

Если вы хотите использовать выборку по меткам (label selection) для указания пространств имён, в которых роль будет действовать, StarVault должен иметь право читать объекты Namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: k8s-full-secrets-abilities-with-labels
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["serviceaccounts", "serviceaccounts/token"]
  verbs: ["create", "update", "delete"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings", "clusterrolebindings"]
  verbs: ["create", "update", "delete"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles", "clusterroles"]
  verbs: ["bind", "escalate", "create", "update", "delete"]

Получение корректных прав для StarVault может потребовать проб и ошибок, поскольку Kubernetes строго ограничивает возможность повышения привилегий. Подробнее читайте в документации по RBAC Kubernetes.

Защищайте сервисный аккаунт StarVault, особенно если он имеет расширенные права — фактически он выполняет роль администратора кластера.

Создайте привязку (binding), связывающую эту роль с сервисным аккаунтом StarVault и предоставляющую ему право управления токенами:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: starvault-token-creator-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k8s-minimal-secrets-abilities
subjects:
- kind: ServiceAccount
  name: starvault
  namespace: starvault
```
Для получения дополнительной информации о ролях, сервисных аккаунтах, привязках и токенах ознакомьтесь с документацией по RBAC Kubernetes.

Если StarVault не будет автоматически управлять ролями или сервисными аккаунтами (см. раздел «Автоматическое управление ролями и аккаунтами»), необходимо создать сервисный аккаунт, для которого StarVault будет выдавать токены.

Крайне не рекомендуется использовать один и тот же сервисный аккаунт и для работы StarVault, и для генерации токенов.

В примерах ниже будет использоваться пространство имён test. Создайте его, если это пространство имён ещё не создано:

$ kubectl create namespace test
namespace/test created

Простой пример сервисного аккаунта, роли и привязки роли в пространстве имён test:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-service-account-with-generated-token
  namespace: test
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test-role-list-pods
  namespace: test
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-role-abilities
  namespace: test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: test-role-list-pods
subjects:
- kind: ServiceAccount
  name: test-service-account-with-generated-token
  namespace: test

Создайте эти объекты с помощью kubectl apply -f.

Включите механизм секретов Kubernetes:
```
$ starvault secrets enable kubernetes
Success! Enabled the kubernetes Secrets Engine at: kubernetes/
```
По умолчанию механизм монтируется по имени kubernetes/. Это можно изменить с помощью аргумента -path.
Настройте точки монтирования. Пустая конфигурация допустима:
```
$ starvault write -f kubernetes/config
```
Доступные параметры конфигурации описаны в документации API.
Теперь вы можете настроить механизм Kubernetes Secrets Engine для создания роли StarVault (не путать с Kubernetes Role), которая может генерировать токены для заданного сервисного аккаунта:
```
$ starvault write kubernetes/roles/my-role \
    allowed_kubernetes_namespaces="*" \
    service_account_name="test-service-account-with-generated-token" \
    token_default_ttl="10m"
```

2. Генерация учетных данных

После того как пользователь прошёл аутентификацию в StarVault и имеет соответствующие разрешения, выполнение записи в конечную точку creds для заданной роли StarVault приведёт к генерации и возврату нового токена сервисного аккаунта.

$ starvault write kubernetes/creds/my-role \
    kubernetes_namespace=test

**Вывод:**
Key	Value
---	----
lease_id	kubernetes/creds/my-role/31d771a6-…
lease_duration	10m0s
lease_renwable	false
service_account_name	test-service-account-with-generated-token
service_account_namespace	test
service_account_token	eyJHbGci0iJSUzI1NiIsImtpZCI6ImlrUEE…

Вы можете использовать выданный токен сервисного аккаунта (eyJHbG…) для любых запросов к API Kubernetes, на которые у этого аккаунта есть права (через привязки ролей).

Пример запроса к API:

$ curl -sk $(kubectl config view --minify -o 'jsonpath={.clusters[].cluster.server}')/api/v1/namespaces/test/pods \
    --header "Authorization: Bearer eyJHbGci0iJSUzI1Ni..."

Пример ответа:

{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "1624"
  },
  "items": []
}

Когда срок аренды истечёт, вы можете убедиться, что токен отозван:

$ curl -sk $(kubectl config view --minify -o 'jsonpath={.clusters[].cluster.server}')/api/v1/namespaces/test/pods \
    --header "Authorization: Bearer eyJHbGci0iJSUzI1Ni..."

Пример ответа при истекшем токене:

{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "Unauthorized",
  "reason": "Unauthorized",
  "code": 401
}

3. TTL (время жизни токена)

Токены сервисных аккаунтов Kubernetes имеют время жизни (TTL). Когда токен истекает, он автоматически отзывается.

Вы можете задать TTL по умолчанию (token_default_ttl) и максимальное TTL (token_max_ttl) при создании или настройке роли StarVault:

$ starvault write kubernetes/roles/my-role \
    allowed_kubernetes_namespaces="*" \
    service_account_name="test-service-account-with-generated-token" \
    token_default_ttl="10m" \
    token_max_ttl="2h"

Также можно указать время жизни токена (TTL) при генерации токена через конечную точку creds. Если значение ttl не указано, используется значение по умолчанию. Оно не может превышать максимальное TTL, заданное для роли:

$ starvault write kubernetes/creds/my-role \
    kubernetes_namespace=test \
    ttl=20m

**Вывод:**
Key	Value
---	----
lease_id	kubernetes/creds/my-role/31d771a6-…
lease_duration	20m0s
lease_renewable	false
service_account_name	test-service-account-with-generated-token
service_account_namespace	test
service_account_token	eyJHbGci0iJSUzI1NiIsImtpZCI6ImlrUEE…

Вы можете проверить TTL токена, расшифровав JWT и извлекая поля iat (время выдачи) и exp (время истечения):

$ echo 'eyJhbGc...' | cut -d'.' -f2 | base64 -d | jq -r '.iat,.exp|todate'
2022-05-20T17:14:50Z
2022-05-20T17:34:50Z

4. Аудитории

Токены сервисных аккаунтов Kubernetes поддерживают аудитории.

Вы можете задать аудитории по умолчанию (token_default_audiences) при создании или настройке роли StarVault. Если не указано явно, будут использоваться аудитории по умолчанию, заданные в настройках кластера Kubernetes.

$ starvault write kubernetes/roles/my-role \
    allowed_kubernetes_namespaces="*" \
    service_account_name="test-service-account-with-generated-token" \
    token_default_audiences="custom-audience"

Также можно указать аудитории (audiences) напрямую при генерации токена через конечную точку creds. Если параметр не задан, будут использоваться аудитории по умолчанию, заданные в роли:

$ starvault write kubernetes/creds/my-role \
    kubernetes_namespace=test \
    audiences="another-custom-audience"

**Вывод:**
Key	Value
---	----
lease_id	kubernetes/creds/my-role/SriWQf0bPZ…
lease_duration	768h
lease_renwable	false
service_account_name	test-service-account-with-generated-token
service_account_namespace	test
service_account_token	eyJHbGci0iJSUzI1NiIsImtpZCI6ImlrUEE…

Вы можете проверить аудитории токена, расшифровав JWT:

$ echo 'eyJhbGc...' | cut -d'.' -f2 | base64 -d
{"aud":
["another-custom-audience"
]...}

5. Автоматическое управление ролями и сервисными аккаунтами

При настройке роли StarVault вы можете указать параметры, позволяющие автоматически создавать сервисный аккаунт Kubernetes и привязку роли (role binding), а при необходимости — и саму роль Kubernetes.

Если вы хотите использовать существующую роль Kubernetes, но при этом автоматически создавать сервисный аккаунт и привязку роли, задайте параметр kubernetes_role_name:

$ starvault write kubernetes/roles/auto-managed-sa-role \
    allowed_kubernetes_namespaces="test" \
    kubernetes_role_name="test-role-list-pods"

Сервисный аккаунт StarVault также должен иметь доступ к ресурсам, к которым он предоставляет доступ. Это можно обеспечить, выполнив следующую команду

kubectl -n test create clusterrolebinding --clusterrole k8s-full-secrets-abilities --serviceaccount=starvault:starvault starvault-test-role-abilities

Это часть механизма Kubernetes по защите от повышения привилегий. Подробнее — в документации по RBAC Kubernetes.

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

$ starvault write kubernetes/creds/auto-managed-sa-role \
    kubernetes_namespace=test

**Вывод:**
Key	Value
---	----
lease_id	kubernetes/creds/auto-managed-sa-role/cujRLYjKZUMQk6dkHBGGWm67
lease_duration	768h
lease_renwable	false
service_account_name	v-token-auto-man-1653001548-5z6hrgsxnmzncxejztml4arz
service_account_namespace	test
service_account_token	eyJHbGci0iJSUzI1Ni…

StarVault также может автоматически создавать роль, помимо сервисного аккаунта и привязки роли. Для этого используется параметр generated_role_rules, принимающий правила в формате JSON или YAML:

$ starvault write kubernetes/roles/auto-managed-sa-and-role \
    allowed_kubernetes_namespaces="test" \
    generated_role_rules='{"rules":[{"apiGroups":[""],"resources":["pods"],"verbs":["list"]}]}'

Получение учётных данных выполняется аналогично:

$ starvault write kubernetes/creds/auto-managed-sa-and-role \
    kubernetes_namespace=test

**Вывод:**
Key	Value
---	----
lease_id	kubernetes/creds/auto-managed-sa-and-role/pehLtegoTP8vCkcaQozUqOHf
lease_duration	768h
lease_renwable	false
service_account_name	v-token-auto-man-1653002096-4imxf3ytjh5hbyro9s1oqdo3
service_account_namespace	test
service_account_token	eyJHbGci0iJSUzI1Ni…

6. API

Механизм секретов Kubernetes в StarVault предоставляет полный HTTP API. Подробнее см. в документации по Kubernetes Secrets Engine API.