kube-apiserver Configuration (v1alpha1)

Endpoint колектора, куди цей компонент буде надсилати трасування. Зʼєднання є незахищеним і наразі не підтримує TLS. Рекомендується не вказувати, і використовувати стандартно otlp grpc localhost:4317.

SamplingRatePerMillion — це кількість зразків, які потрібно збирати на мільйон проміжків. Рекомендується не вказувати. Якщо не вказано, зразок буде відповідати ставці зразка батьківського проміжку, але інакше ніколи не буде зібраний.

Plugins дозволяє вказати конфігурацію для кожного втулка контролю допуску.

jwt — це список автентифікаторів для автентифікації користувачів Kubernetes за допомогою JWT-сумісних токенів. Автентифікатор спробує розпарсити ID токен, перевірити, чи він підписаний налаштованим постачальником. Публічний ключ для перевірки підпису знаходиться на публічній точці доступу постачальника, використовуючи OIDC discovery. Для вхідного токена кожен JWT-автентифікатор буде спробований у порядку, в якому він зазначений у цьому списку. Зверніть увагу, що інші автентифікатори можуть запускатися до або після JWT-автентифікаторів. Специфічне розташування JWT-автентифікаторів відносно інших автентифікаторів не визначено і не є стабільним у різних версіях. Оскільки кожен JWT-автентифікатор повинен мати унікальний URL постачальника, в більшості випадків лише один JWT-автентифікатор спробує криптографічно перевірити токен.

Мінімальне дійсне наповнення JWT повинно містити наступні вимоги:

{
"iss": "https://issuer.example.com",
"aud": ["audience"],
"exp": 1234567890,
"": "username"
}

Authorizers — це впорядкований список авторизаторів для авторизації запитів. Це схоже на прапорец --authorization-modes в kube-apiserver. Повинен бути принаймні один.

connectionServices містить список конфігурацій клієнтів вибору виходу.

Вбудувати структуру конфігурації трасування компонента.

Name — це імʼя контролера допуску. Воно повинно відповідати зареєстрованому імені втулка допуску.

Path — це шлях до конфігураційного файлу, що містить конфігурацію втулка.

Configuration — це вбудований обʼєкт конфігурації, який буде використовуватися як конфігурація втулка. Якщо він присутній, він буде використовуватися замість шляху до конфігураційного файлу.

Шлях для якого увімкнено анонімну автентифікацію.

Якщо встановлено, анонімна автентифікація дозволена, тільки якщо запит відповідає одній з умов.

Type визначає тип авторизатора. "Webhook" підтримується в загальному API-сервері. Інші API-сервери можуть підтримувати додаткові типи авторизаторів, такі як Node, RBAC, ABAC тощо.

Name використовується для опису вебхука. Це явно використовується в механізмах моніторингу для метрик. Примітка: Імена повинні бути у форматі DNS1123, такі як myauthorizername або піддомени, такі як myauthorizer.example.domain. Обовʼязково, без стандартного значення.

Webhook визначає конфігурацію для вебхук-авторизатора. Повинна бути визначена, коли Type=Webhook. Не повинна бути визначена, коли Type!=Webhook.

username представляє опцію для атрибута імені користувача. Значення заявки повинно бути єдиним рядком. Також використовується для прапорців --oidc-username-claim і --oidc-username-prefix. Якщо встановлено username.expression, вираз повинен повертати значення рядка. Якщо username.expression використовує 'claims.email', тоді 'claims.email_verified' повинно бути використане в username.expression або extra[].valueExpression or claimValidationRules[].expression. Приклад виразу правил перевірки заявок, який відповідає перевірці, автоматично застосованій, коли username.claim встановлено в 'email', є 'claims.?email_verified.orValue(true)'.

У підході на основі прапорців, --oidc-username-claim і --oidc-username-prefix є необовʼязковими. Якщо --oidc-username-claim не встановлено, стандартне значення — "sub". Для конфігурації автентифікації немає стандартного значення для заявки або префікса. Заявка та префікс повинні бути явно встановлені. Для заявки, якщо --oidc-username-claim не був встановлений з допомогою підходу старого прапорця, налаштуйте username.claim="sub" у конфігурації автентифікації. Для префікса: (1) --oidc-username-prefix="-" не додає префікс до імені користувача. Для такої ж поведінки, використовуючи конфігурацію автентифікації, налаштуйте username.prefix="" (2) --oidc-username-prefix="" і --oidc-username-claim != "email", префікс був ""<value of --oidc-issuer-url>#". Для такої ж поведінки, використовуючи конфігурацію автентифікації, налаштуйте username.prefix="#" (3) --oidc-username-prefix="". Для такої ж поведінки, використовуючи конфігурацію автентифікації, налаштуйте username.prefix=""

groups представляє опцію для атрибута груп. Значення заявки повинно бути рядком або масивом рядків. Якщо встановлено groups.claim, префікс повинен бути зазначений (і може бути пустим рядком). Якщо встановлено groups.expression, вираз повинен повертати рядок або масив рядків. "" (пустий рядок), [] (пустий масив) і null значення трактуються як відсутність зіставлення груп.

uid представляє опцію для атрибута uid. Заявка повинна бути єдиним рядком. Якщо встановлено uid.expression, вираз повинен повертати рядок.

extra представляє опцію для атрибута extra. вираз повинен повертати рядок або масив рядків. Якщо значення порожнє, відображення extra не буде присутнім.

жорстко закодоване додаткові ключ/значення

• key: "foo" valueExpression: "'bar'" Це призведе до додаткового атрибута — foo: ["bar"]

жорстко закодований ключ копіює значення заявки

• key: "foo" valueExpression: "claims.some_claim" Це призведе до додаткового атрибута — foo: [value of some_claim]

жорстко закодований ключ, значення, що походить від значення заявки

• key: "admin" valueExpression: '(has(claims.is_admin) && claims.is_admin) ? "true":"' Це призведе до:
• якщо заявка is_admin присутня і true, додатковий атрибут — admin: ["true"]
• якщо заявка is_admin присутня і false або заявка is_admin відсутня, жоден додатковий атрибут не буде доданий

claim — це заявка JWT, яку потрібно використовувати. Або claim, або expression повинно бути встановлено. Взаємно виключаються в expression.

expression представляє вираз, який буде оцінений CEL.

Вирази CEL мають доступ до вмісту заявок токена, організованих у змінні CEL:

• 'claims' це map назв заявок до значень заявок. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою позначки крапки, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємно виключаються в claim.

claim — це імʼя обовʼязкової заявки. Також використовується для прапорця --oidc-required-claim. Підтримуються тільки рядкові ключі заявок. Взаємно виключається в expression і message.

requiredValue — це значення обовʼязкової заявки. Також використовується для прапорця --oidc-required-claim. Підтримуються тільки рядкові значення заявок. Якщо claim встановлено, а requiredValue не встановлено, заявка повинна бути присутньою зі значенням, встановленим у порожній рядок. Взаємно виключається з expression і message.

expression представляє вираз, який буде оцінений CEL. Повинно повернути boolean.

Вирази CEL мають доступ до вмісту заявок токена, організованих у змінні CEL:

• 'claims' це map назв заявок до значень заявок. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою позначки крапки, наприклад, 'claims.foo.bar'. Повинно повернути true для проходження перевірки.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Взаємно виключається в claim і requiredValue.

message налаштовує повернуте повідомлення про помилку, коли вираз повертає false. message є літеральним рядком. Взаємно виключається з claim і requiredValue.

proxyProtocol — це протокол, який використовується для підключення клієнта до сервера konnectivity.

transport визначає конфігурації транспорту, які ми використовуємо для зʼєднання з сервером konnectivity. Це потрібно, якщо ProxyProtocol — HTTPConnect або GRPC.

name — це назва egress selection. Підтримувані значення: "controlplane", "master", "etcd" та "cluster". "master" egress selector застарілий і замінений на "controlplane".

connection — це точна інформація, що використовується для налаштування egress selection.

key — це рядок, що використовується як ключ додаткового атрибуту. key повинен бути шляхом з префіксом домену (наприклад, example.org/foo). Усі символи перед першим "/" повинні бути дійсним піддоменом, як визначено у RFC 1123. Усі символи після першого "/" повинні бути дійсними символами шляху HTTP, як визначено у RFC 3986. key повинен бути у нижньому регістрі. Має бути унікальним.

valueExpression — це вираз CEL для вилучення значення додаткового атрибуту. valueExpression повинен виробляти рядкове або масив рядкових значень. "", [], і null значення трактуються як відсутність додаткового зіставлення. Порожні рядкові значення, що містяться в масиві рядків, відфільтровуються.

Вирази CEL мають доступ до вмісту заявок токена, організованих у змінній CEL:

• 'claims' це map назв заявок до значень заявок. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою позначки крапки, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

url вказує на URL-адресу видавця у форматі https://url або https://url/path. Це повинно відповідати заявці "iss" у поданому JWT і видавцю, повернутому з виявлення. Те ж саме значення, що і прапорець --oidc-issuer-url. Інформація про виявлення отримується з "{url}/.well-known/openid-configuration", якщо не перевизначено за допомогою discoveryURL. Має бути унікальним для всіх JWT автентифікаторів. Зверніть увагу, що конфігурація вибору egress не використовується для цього мережевого зʼєднання.

discoveryURL, якщо вказано, перевизначає URL, який використовується для отримання інформації про виявлення, замість використання "{url}/.well-known/openid-configuration". Використовується точне вказане значення, тому "/.well-known/openid-configuration" повинно бути включено в discoveryURL, якщо це потрібно.

Поле "issuer" у отриманій інформації про виявлення повинно відповідати полю "issuer.url" у AuthenticationConfiguration і буде використовуватися для перевірки заявки "iss" у поданому JWT. Це для сценаріїв, коли точки доступу well-known і jwks розміщені в іншому місці, ніж видавець (наприклад, локально в кластері).

Приклад: URL виявлення, який опублікований за допомогою сервіса kubernetes 'oidc' у просторі імен 'oidc-namespace', а інформація про виявлення доступна за адресою '/.well-known/openid-configuration'. discoveryURL: "https://oidc.oidc-namespace/.well-known/openid-configuration" certificateAuthority використовується для перевірки зʼєднання TLS, а імʼя хоста на сертифікаті повинно бути встановлено як 'oidc.oidc-namespace'.

curl https://oidc.oidc-namespace/.well-known/openid-configuration (.discoveryURL field) { issuer: "https://oidc.example.com" (.url field) }

discoveryURL повинен відрізнятися від url. Має бути унікальним для всіх JWT автентифікаторів. Зверніть увагу, що конфігурація вибору egress не використовується для цього мережевого зʼєднання.

certificateAuthority містить PEM-кодовані сертифікати органу сертифікації, які використовуються для перевірки зʼєднання під час отримання інформації про виявлення. Якщо не встановлено, використовується системний перевіряючий. Те ж саме значення, що і вміст файлу, на який посилається прапорець --oidc-ca-file.

audiences — це набір прийнятних аудиторій, до яких повинен бути виданий JWT. Принаймні один з записів повинен відповідати заявці "aud" у поданих JWT. Те ж саме значення, що і прапорець --oidc-client-id (хоча це поле підтримує масив). Має бути непорожнім.

audienceMatchPolicy визначає, як поле "audiences" використовується для відповідності заявці "aud" у поданому JWT. Допустимі значення:

1. "MatchAny" при вказанні кількох аудиторій та
2. порожній (або не встановлений) або "MatchAny" при вказанні однієї аудиторії.

• MatchAny: заявка "aud" у поданому JWT повинна відповідати принаймні одному з записів у полі "audiences". Наприклад, якщо "audiences" — ["foo", "bar"], заявка "aud" у поданому JWT повинна містити або "foo", або "bar" (і може містити обидва).

• "": Політика відповідності може бути порожньою (або не встановленою) при вказанні однієї аудиторії у полі "audiences". Заявка "aud" у поданому JWT повинна містити одну аудиторію (і може містити інші).

Для більш детальної перевірки аудиторій використовуйте claimValidationRules. приклад: claimValidationRule[].expression: 'sets.equivalent(claims.aud, ["bar", "foo", "baz"])' для вимоги точної відповідності.

issuer містить основні параметри підключення постачальника OIDC.

claimValidationRules — це правила, які застосовуються для перевірки заявок токена для автентифікації користувачів.

claimMappings вказує заявки токена, які будуть розглядатися як атрибути користувача.

userValidationRules - це правила, які застосовуються до кінцевого користувача перед завершенням автентифікації. Ці правила дозволяють застосовувати інваріанти до вхідних ідентичностей, такі як запобігання використанню префіксу system:, який зазвичай використовується компонентами Kubernetes. Правила перевірки поєднуються логічним AND і повинні всі повертати true для успішної перевірки.

claim — це заявка JWT для використання. Є взаємовиключою з expression.

prefix додається до значення заявки, щоб уникнути конфліктів з існуючими іменами. prefix повинен бути встановлений, якщо встановлена заявка, і може бути порожнім рядком. Взаємовиключається з expression.

expression представляє вираз, який буде оцінюватися CEL.

CEL вирази мають доступ до вмісту заявок токена, організованого в CEL змінну:

• 'claims' — це мапа імен заявок до їх значень. Наприклад, змінну з іменем 'sub' можна отримати як 'claims.sub'. Вкладені заявки можна отримати за допомогою нотації крапок, наприклад, 'claims.foo.bar'.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

Є взаємовиключною з claim і prefix.

URL — це місцезнаходження сервера konnectivity, до якого потрібно підʼєднатися. Наприклад, це може бути https://127.0.0.1:8131"

TLSConfig — конфігурація, необхідна для використання TLS при підключенні до сервера konnectivity

caBundle — це розташування файлу з CA, який буде використовуватися для встановлення довіри з konnectivity server. Повинно бути відсутнім/порожнім, якщо URL TCPTransport має префікс http://. Якщо відсутній, коли URL TCPTransport має префікс https://, стандартно використовуються системні корені довіри.

clientKey — це розташування файлу з ключем клієнта, який буде використовуватися в mtls-рукостисканнях з konnectivity server. Повинно бути відсутнім/порожнім, якщо URL TCPTransport має префікс http://. Повинно бути налаштованим, якщо URL TCPTransport має префікс https://

clientCert — це розташування файлу з сертифікатом клієнта, який буде використовуватися в mtls-рукостисканнях з konnectivity server. Повинно бути відсутнім/порожнім, якщо URL TCPTransport має префікс http://. Повинно бути налаштованим, якщо URL TCPTransport має префікс https://

TCP — це конфігурація TCP для звʼязку з konnectivity server через TCP. ProxyProtocol з GRPC наразі не підтримується з TCP транспортом. Потрібно налаштувати принаймні один з TCP або UDS.

UDS — це конфігурація UDS для звʼязку з konnectivity server через UDS. Потрібно налаштувати принаймні один з TCP або UDS.

UDSName — це назва unix domain socket для підключення до konnectivity server. Це не використовує префікс unix://. (Наприклад: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket)

expression представляє вираз, який буде оцінюватися CEL. Повинен повернути true, щоб перевірка пройшла успішно.

CEL вирази мають доступ до вмісту UserInfo, організованого в CEL змінну:

• 'user' - authentication.k8s.io/v1, Обʼєкт Kind=UserInfo Див. https://github.com/kubernetes/api/blob/release-1.28/authentication/v1/types.go#L105-L122 для визначення. API документація: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#userinfo-v1-authentication-k8s-io

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/

message налаштовує повернуте повідомлення про помилку, коли правило повертає false. message є літеральним рядком.

Тривалість кешування відповідей "authorized" від вебхука авторизатора. Те ж саме, що й встановлення прапорця --authorization-webhook-cache-authorized-ttl Стандартно: 5m0s

Тривалість кешування відповідей "unauthorized" від вебхука авторизатора. Те ж саме, що й встановлення прапорця --authorization-webhook-cache-unauthorized-ttl Стандартно: 30s

Час очікування відповіді від вебхука Максимально дозволене значення — 30s. Обовʼязкове, стандартне значення відсутнє.

Версія API authorization.k8s.io SubjectAccessReview, яку потрібно відправити та очікувати від вебхука. Те ж саме, що й встановлення прапорця --authorization-webhook-version Дійсні значення: v1beta1, v1. Обовʼязкове, стандартне значення відсутнє

MatchConditionSubjectAccessReviewVersion визначає версію SubjectAccessReview, яку використовують для оцінки виразів CEL. Дійсні значення: v1. Обовʼязкове, стандартне значення відсутнє

Контролює рішення про авторизацію, коли запит вебхука не вдається завершити або повертає некоректну відповідь або помилки при оцінці matchConditions. Дійсні значення:

• NoOpinion: продовжити до наступних авторизаторів, щоб побачити, чи один з них дозволить запит
• Deny: відхилити запит без консультації з наступними авторизаторами. Обовʼязкове, стандартне значення відсутнє.

ConnectionInfo визначає, як ми спілкуємося з вебхуком

matchConditions — це список умов, які мають бути виконані, щоб запит було надіслано на цей вебхук. Порожній список matchConditions відповідає всім запитам. Максимально допустимо 64 умови відповідності.

Точна логіка відповідності (в порядку):

1. Якщо принаймні одна умова відповідності оцінюється як FALSE, то вебхук пропускається.
2. Якщо ВСІ умови відповідності оцінюються як TRUE, то вебхук викликається.
3. Якщо принаймні одна умова відповідності оцінюється як помилка (але жодна з них не є FALSE):
   • Якщо failurePolicy=Deny, то вебхук відхиляє запит
   • Якщо failurePolicy=NoOpinion, то помилка ігнорується, і вебхук пропускається

Контролює, як вебхук повинен спілкуватися з сервером. Дійсні значення:

• KubeConfigFile: використовувати файл, зазначений у kubeConfigFile, щоб знайти сервер.
• InClusterConfig: використовувати внутрішньокластерну конфігурацію для виклику SubjectAccessReview API, який розміщений kube-apiserver. Цей режим не дозволено для kube-apiserver.

Шлях до KubeConfigFile для інформації про підключення. Обовʼязково, якщо connectionInfo.Type є KubeConfig

expression представляє вираз, який буде оцінюватися за допомогою CEL. Повинен оцінюватися як bool. CEL вирази мають доступ до вмісту SubjectAccessReview у версії v1. Якщо версія, вказана в subjectAccessReviewVersion у змінній запиту, є v1beta1, вміст буде перетворено на версію v1 перед оцінкою виразу CEL.

Документація з CEL: https://kubernetes.io/docs/reference/using-api/cel/