Kube-rbac-proxy#

Kube-rbac-proxy — это HTTP-прокси для одного исходящего потока, который может выполнять авторизацию RBAC для DropApp API с помощью SubjectAccessReview.

В кластерах DropApp без применения сетевой политики любой pod может выполнять запросы к любому другому pod в кластере. Используйте Kube-rbac-proxy для ограничения запросов только теми модулями, которые предоставляют действительный и авторизованный RBAC токен или клиентский TLS-сертификат.

Преимущества использования Kube-rbac-proxy:

  • разгружает API DropApp, чтобы он мог обрабатывать фактические запросы, связанные с компонентами кластера, а не запросы от клиентов;

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

При входящем запросе Kube-rbac-proxy выясняет, какой пользователь выполняет запрос. Kube-rbac-proxy поддерживает использование клиентских TLS-сертификатов, а также токенов. В случае использования сертификата, он проверяется настроенным центром сертификации.

После того как пользователь прошел аутентификацию, снова используется authentication.k8s.io для выполнения SubjectAccessReview, чтобы авторизовать соответствующий запрос и убедиться, что аутентифицированный пользователь имеет необходимые роли RBAC.

У Kube-rbac-proxy есть все glog флаги для ведения журнала. Чтобы использовать Kube-rbac-proxy, установите несколько флагов:

  • --upstream: - исходящий поток проксирования;

  • --config-file: - файл, в котором указаны сведения о SubjectAccessReview, их необходимо выполнить по запросу. Например, можно указать, что объекту, выполняющему запрос, должно быть разрешено выполнять развертывание get pod с названием my-frontend-app.

Все флаги командной строки Kube-rbac-proxy представлены в таблице ниже.

Флаги командной строки Kube-rbac-proxy#

Синтаксис флага

Значение

--allow-paths strings

Список путей, разделенных запятыми, по которым шаблон Kube-rbac-proxy сопоставляет входящий запрос. Если запрос не совпадает, Kube-rbac-proxy отвечает кодом состояния 404. Если этот параметр опущен, путь входящего запроса не проверяется. Нельзя использовать с параметром --ignore-paths

--auth-header-fields-enabled

Значение true данного флага позволяет Kube-rbac-proxy добавлять поля, связанные с аутентификацией, в заголовки HTTP-запросов, отправляемых в исходящий поток

--auth-header-groups-field-name string

Имя поля в заголовке запроса HTTP/2, чтобы сообщить вышестоящему серверу о группах пользователя (по умолчанию x-remote-groups)

--auth-header-groups-field-separator string

Разделитель, используемый для объединения нескольких имен групп в значении поля заголовка группы (по умолчанию ┃)

--auth-header-user-field-name string

Имя поля в заголовке запроса HTTP(2), сообщающее вышестоящему серверу об имени пользователя (по умолчанию x-remote-user)

--auth-token-audiences strings

Список аудиторий токенов, которые необходимо принять, разделенный запятыми. По умолчанию токен не должен иметь какой-либо конкретной аудитории. Рекомендуется установить конкретную аудиторию

--client-ca-file

Любой запрос, представляющий сертификат клиента, подписанный одним из уполномоченных в файле client-ca, в случае установки флага, аутентифицируется с использованием идентификатора, соответствующего CommonName сертификата клиента

--config-file string

Файл конфигурации для настройки Kube-rbac-proxy

--ignore-paths strings

Список путей, разделенных запятыми, по которым шаблон Kube-rbac-proxy сопоставляет входящий запрос. Если запрос совпадает, он перенаправляет запрос без выполнения аутентификации или проверки авторизации. Нельзя использовать с флагом --allow-paths

--kubeconfig

Путь к файлу kubeconfig*, указывающий, как подключиться к серверу API. Если значение --kubeconfig не задано, будет использоваться конфигурация внутри кластера

--oidc-ca-file

Сертификат сервера OpenID будет проверен в файле oidc-ca при установке флага, в противном случае будет использоваться корневой набор CA хоста

--oidc-clientID

Идентификатор клиента для клиента OpenID Connect должен быть установлен, если установлен oidc-issuer-url

--oidc-groups-claim string

Идентификатор групп в заявке JWT

--oidc-groups-prefix string

Флаг, при установке которого все группы будут иметь префикс с этим значением, чтобы предотвратить конфликты с другими стратегиями аутентификации

--oidc-issuer string

URL-адрес издателя OpenID, должен быть указан только в формате HTTPS. Если он установлен, он будет использоваться для проверки веб-токена OIDC JSON (JWT)

--oidc-sign-alg stringArray

Поддерживаемые алгоритмы подписи, по умолчанию RS256

--oidc-username-claim string

Идентификатор пользователя в заявлении JWT, по умолчанию установлено значение «электронная почта»

--proxy-endpoints-port int

Порт для безопасного обслуживания конечных точек, специфичных для прокси-сервера (например, healthz). Использует хост из --secure-listen-address

--secure-listen-address string

Адрес, который должен прослушивать HTTP-сервер Kube-rbac-proxy

--tls-cert-file string

Файл, содержащий сертификат x509 по умолчанию для HTTPS. Сертификат ЦС, если таковой имеется, объединенный после сертификата сервера

--tls-cipher-suites strings

Список наборов шифров для сервера, разделенный запятыми. Если этот параметр не указан, будут использоваться наборы шифров Go по умолчанию

--tls-min-version  string

Минимальная поддерживаемая версия TLS 1.2. По умолчанию ВTLS12

--tls-private-key-file string

Файл, содержащий закрытый ключ x509 по умолчанию, соответствующий --tls-cert-file

--tls-reload-interval duration

Интервал, с которым следует отслеживать изменения сертификата TLS 1.2, по умолчанию равен одной минуте

--upstream string

Исходящий URL-адрес для прокси-сервера после успешной аутентификации и авторизации запросов

--upstream-ca-file string

ЦС, который исходящий поток использует для TLS 1.2-соединения. Это необходимо, когда исходящий поток использует TLS 1.2 и собственный сертификат ЦС

--upstream-client-cert-file  string

Флаг, при установке которого клиент будет использоваться для аутентификации прокси-сервера в исходящем направлении. Также требуется установить --upstream-client-key-file

--upstream-client-key-file string

Флаг, соответствующий сертификату из --upstream-client-cert-file. При установке, требуется также установить --upstream-client-cert-file

--upstream-force-h2c

Флаг, заставляющий h2c взаимодействовать с исходящим потоком. Это необходимо, когда исходящий поток использует только h2c (открытый текст HTTP/2 — небезопасный вариант HTTP/2). Например, сервер go-grpc в небезопасном режиме без TLS 1.2

Глобальные флаги:

-h, --help

Помощь для Kube-rbac-proxy

--log-dir string

Флаг, позволяющий записывать файлы журналов в текущий каталог (не ведет запись, если -logtostderr=true)

--version version[=true]

Флаг, позволяющий вывести информацию о версии и выйти из приложения

RBAC различается по двум типам, которые необходимо авторизовать: ресурсные и нересурсные. Например, авторизация запроса ресурса может заключаться в том, что запрашивающему объекту необходимо авторизоваться для выполнения действия get при развертывании DropApp.

Выполните следующие действия для защиты приложения с помощью Kube-rbac-proxy (в примере ниже - prometheus-example-app). В этом примере запрашивающему объекту разрешено вызывать подресурс proxy в службе DropApp с именем kube-rbac-proxy. Это настраивается в файле, переданном Kube-rbac-proxy с флагом --config-file. Кроме того, необходимо установить флаг --upstream для настройки приложения, которое должно быть проксировано при успешной аутентификации и авторизации.

Kube-rbac-proxy также требует доступа RBAC для выполнения TokenReviews, а также SubjectAccessReviews. Это API-интерфейсы, доступные в DropApp API для аутентификации и последующей проверки авторизации объекта.