Прокси-приложение K8S, делегирующее аутентификацию запросов от других модулей - PullRequest
Новая
       22

Прокси-приложение K8S, делегирующее аутентификацию запросов от других модулей

3 голосов
/ 25 апреля 2019

Справочная информация

У меня есть кластер K8S с несколькими различными модулями, которые имеют собственные учетные записи служб, роли кластеров и привязки ролей кластера, чтобы они могли выполнять различные запросы на чтение / запись.непосредственно с помощью API REST K8S.Есть несколько сложных запросов, которые могут быть выполнены, и я хотел бы сделать функцию, чтобы обернуть сложную логику.Тем не менее, различные сервисы в кластере написаны на нескольких (то есть 6+) языках программирования, и, похоже, нет (пока) тривиального способа разрешить всем этим сервисам напрямую повторно использовать этот код.

Я рассматриваю вопрос о создании «прокси» -сервисного микросервиса, который предоставляет собственный REST API, выдает необходимые запросы и обрабатывает «сложную логику» от имени клиента.

Проблема

Единственная проблема заключается в том, что в текущей модели развертывания клиент может запросить, чтобы прокси-микросервис выполнял HTTP-запрос, который сам клиент не имеет права делать.

Вопрос

Существует ли простой / простой способ для одного модуля, например, идентифицировать клиентский модуль и выполнить какую-либо операцию запроса / результата политики (т. Е. Путем делегирования аутентификацииСам механизм аутентификации кластера K8S), чтобы определить, должен ли он выполнить запрос от клиентского модуля?

1 Ответ

0 голосов
/ 19 июня 2019

Kubernetes Аутентификация * Модель 1002 * представляет способ, которым конкретная учетная запись пользователя или службы может быть назначена в кластере k8s, однако методы Авторизация определяют, был ли первоначальный запрос от посетителя кластера направлен на выполнениенекоторые действия над ресурсами / объектами кластера имеют достаточные разрешения, чтобы сделать это возможным.

Из-за того, что вы использовали определенные учетные записи служб для каждого модуля Pod всего кластера и предоставили им конкретные RBAC правила, возможно использовать API SelfSubjectAccessReview для проверки запросов к REST API k8s и определения, имеет ли клиентская учетная запись службы Pod соответствующие разрешения для выполнения каких-либо действий в целевом пространстве имен Pod.

Этого можно добиться, используя подкоманду kubectl auth can-i , предоставив необходимую информацию для олицетворения пользователя.

Я предполагаю, что вы также можете запросить группу API авторизации k8s в схеме запроса HTTP итогда рструктурированные данные задницы из формата JSON / YAML, как в примере ниже:

Обычная kubectl auth can-i команда для проверки, может ли default SA получать данные о модулях в default пространстве имен:

kubectl auth can-i get pod --as system:serviceaccount:default:default

Эквивалентный метод через HTTP-вызов к REST API k8s с использованием JSON-типа контента в Bearer Токен аутентификация: 

curl -k \
    -X POST \
    -d @- \
    -H "Authorization: Bearer $MY_TOKEN" \
    -H 'Accept: application/json' \
    -H "Impersonate-User: system:serviceaccount:default:default" \
    -H 'Content-Type: application/json' \
    https://<API-Server>/apis/authorization.k8s.io/v1/selfsubjectaccessreviews <<'EOF'
{
  "kind": "SelfSubjectAccessReview",
  "apiVersion": "authorization.k8s.io/v1",
  "spec":{"resourceAttributes":{"namespace":"default","verb":"get","resource":"pods"}}
}
EOF

Вывод:

.... "status": {"позволено": истина, "причина": "RBAC: разрешено RoleBinding ....

...