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

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

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

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

Мінімальний дійсне корисне навантаження JWT повинно містити наступні вимоги: { "iss": "https://issuer.example.com", "aud": ["audience"], "exp": 1234567890, "": "username" }

Якщо присутній, --anonymous-auth не повинен бути встановлений

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

resources — це список, що містить ресурси та відповідні їм провайдери шифрування.

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

keys — це список ключів, які використовуються для створення AES-трансформера. Кожен ключ повинен бути 32 байти для AES-CBC та 16, 24 або 32 байти для AES-GCM.

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

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

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

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

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

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

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

Webhook визначає конфігурацію для авторизації 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 або claimValidationRules[].expression. Прикладом виразу правила перевірки заявки, який відповідає перевірці, що автоматично застосовується, коли username.claim встановлено на 'email', є 'claims.?email_verified.orValue(true) == true'. Явно порівнюючи значення з true, ми дозволяємо перевірці типу бачити, що результат буде булевим, і переконуємося, що небулева заявка email_verified буде виявлена під час виконання.

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

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

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

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

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

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

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

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

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

• key: "admin" valueExpression: '(has(claims.is_admin) && claims.is_admin) ? "true":""' Це призведе до:
• якщо is_admin claim присутній і дійсний, додатковий атрибут — admin: ["true"]
• якщо claim is_admin присутня і має значення false або claim 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 — це назва потрібної вимоги. Те саме, що й прапорець --oidc-required-claim. Підтримуються лише ключі вимог типу string. Взаємовиключні з expression та message.

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

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

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

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

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

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

key — це рядок, який використовується як додатковий атрибут 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. Це стосується сценаріїв, коли відомі та jwks точки доступу розміщені в іншому місці, ніж емітент (наприклад, локально в кластері).

Приклад: URL-адреса виявлення, яка відкривається за допомогою сервісу Kubernetes 'oidc' в просторі імен 'oidc-namespace', а інформація про виявлення доступна за адресою '/.well-known/openid-configuration'. discoveryURL: "https://oidc.oidc-namespace/.well-known/openid-configuration" certificateAuthority використовується для перевірки зʼєднання TLS, а імʼя хосту в сертифікаті leaf має бути встановлено на '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"])' для вимагання точної відповідності.

egressSelectorType — це індикатор, який вказує, який селектор egress слід використовувати для надсилання всього трафіку, що має звʼязки з цим емітентом (виявлення, JWKS, розподілені вимоги тощо). Якщо не вказано, номеронабирач користувача не використовується. Якщо вказано, допустимими варіантами є "controlplane" та "cluster". Вони відповідають повʼязаним значенням у --egress-selector-config-file.

• controlplane: для трафіку, призначеного для передачі на панель управління.

• cluster: для трафіку, призначеного для системи, що управляється Kubernetes.

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

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

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

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

apiVersion KeyManagementService

name — це назва втулка KMS,який буде використовуватися.

cachesize — це максимальна кількість секретів, які кешуються в памʼяті. Стандартне значення — 1000. Встановіть негативне значення, щоб вимкнути кешування. Це поле дозволено лише для провайдерів KMS v1.

endpoint — це адреса прослуховувння gRPC сервера, наприклад, "unix:///var/run/kms-provider.sock".

timeout для gRPC викликів до kms-втулка (наприклад, 5 секунд). Стандатне значення — 3 секунди.

name — це імʼя ключа, який буде використовуватися при збереженні даних на диск.

secret — це фактичний ключ, закодований в base64.

claim — це JWT-вимога, яку слід використовувати. Взаємовиключна з expression.

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

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

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

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

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

aesgcm — це конфігурація для трансформера AES-GCM.

aescbc — це конфігурація для трансформера AES-CBC.

secretbox — це конфігурація для трансформера на основі Secretbox.

identity — це (порожня) конфігурація для трансформера ідентичності.

kms містить назву, розмір кешу та шлях до конфігураційного файлу для трансформера конвертів на основі KMS.

resources — це список ресурсів Kubernetes, які мають бути зашифровані. Імена ресурсів походять від resource або resource.group з group/version/resource. Наприклад: pandas.awesome.bears.example — це ресурс користувача з 'group': awesome.bears.example, 'resource': pandas. Використовуйте '\*.\*' для шифрування всіх ресурсів і '\*.\' для шифрування всіх ресурсів у певній групі. Наприклад: '\*.awesome.bears.example' зашифрує всі ресурси у групі 'awesome.bears.example'. Наприклад: '\*.' зашифрує всі ресурси в основній групі (такі як pods, configmaps тощо).

providers — це список трансформерів, які використовуються для читання та запису ресурсів на диск. Наприклад: aesgcm, aescbc, secretbox, identity, kms.

keys — це список ключів, які використовуються для створення трансформера Secretbox. Кожен ключ повинен бути довжиною 32 байти.

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

CacheAuthorizedRequests визначає, чи слід кешувати авторизовані запити. Якщо встановлено значення true, TTL для кешованих рішень можна налаштувати за допомогою поля AuthorizedTTL. Стандартно: true

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

CacheUnauthorizedRequests визначає, чи слід кешувати неавторизовані запити. Якщо встановлено значення true, TTL для кешованих рішень можна налаштувати за допомогою поля UnauthorizedTTL. Стандартно: true

Таймаут для запиту веб-хука. Максимально допустиме значення — 30 секунд. Обовʼязкове, без стандартного значення.

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

MatchConditionSubjectAccessReviewVersion specifies the SubjectAccessReview version the CEL expressions are evaluated against. Допустимі значення: v1. Обовʼязкове, без стандартного значення.

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

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

ConnectionInfo визначає, як ми звʼязуємося з веб-хуком

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

Логіка точного збігу така (по порядку):

1. Якщо хоча б одне значення matchCondition дорівнює FALSE, то вебхук пропускається.
2. Якщо ALL matchConditions мають значення TRUE, то викликається веб-хук.
3. Якщо хоча б одне matchCondition повертає помилку (але жодне з них не є FALSE):
   • If failurePolicy=Deny, тоді веб-хук відхиляє запит
   • If failurePolicy=NoOpinion, то помилка ігнорується і веб-хук пропускається

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

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

Шлях до KubeConfigFile для інформації про зʼєднання. Обов'язковий, якщо connectionInfo. Має тип KubeConfig

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

• 'resourceAttributes' описує інформацію для запиту доступу до ресурсу і не встановлюється для нересурсних запитів, наприклад, has(request.resourceAttributes) && request.resourceAttributes.namespace == 'default'
• 'nonResourceAttributes' описує інформацію для запиту доступу до нересурсів і не встановлюється для запитів до ресурсів. наприклад, has(request.nonResourceAttributes) && request.nonResourceAttributes.path == '/healthz'.
• 'user' — користувач, для якого потрібно перевірити, наприклад, request.user == 'alice'
• 'groups' — це групи, для яких потрібно протестувати, наприклад, ('group1' в request.groups)
• 'extra' відповідає методу user.Info.GetExtra() з автентифікатора.
• 'uid' — інформація про користувача, який надіслав запит, наприклад, request.uid == '1'.

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