Що потрібно знати користувачам Google Kubernetes Engine про нові маркери облікових записів служби Kubernetes

Коли ви розгортаєте програму на Kubernetes, вона працює як обліковий запис служби — системний користувач, зрозумілий площині керування Kubernetes. Обліковий запис служби є основним інструментом для налаштування того, що програмі дозволено робити, аналогічно концепції користувача операційної системи на одній машині. У кластері Kubernetes ви можете використовувати керування доступом на основі ролей, щоб налаштувати, що дозволено робити обліковому запису служби (“перерахувати модулі в усіх просторах імен”, “читати секрети в просторі імен foo”). Під час роботи на Google Kubernetes Engine (GKE) ви також можете використовувати GKE Workload Identity та Cloud IAM, щоб надати сервісним обліковим записам доступ до ресурсів GCP («читати всі об’єкти на панелі сегментів Cloud Storage»).

Як це працює? Як Kubernetes API або Cloud Storage дізнаються, що HTTP-запит надходить із вашої програми, а не з Боба? Це все про токени: точніше, токени облікових записів служби Kubernetes. Коли ваша програма використовує клієнтську бібліотеку Kubernetes для здійснення виклику Kubernetes API, вона додає маркер у заголовок авторизації, який потім перевіряє сервер, щоб перевірити ідентичність вашої програми.

Як ваша програма отримує цей маркер і як працює процес автентифікації? Давайте детальніше розглянемо цей процес, деякі зміни, внесені в Kubernetes 1.21, які покращать автентифікацію Kubernetes, і те, як змінити ваші програми, щоб скористатися перевагами можливостей безпеки.

Застарілі маркери: Kubernetes 1.20 і старіші версії

Давайте розкрутимо стручок і пошмикаємо. Якщо ви слідкуєте за цим, переконайтеся, що ви робите це на кластері 1.20 (або нижче).

  (dev) $ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: basic-debian-pod
  namespace: default
spec:
  serviceAccountName: default
  containers:
  - image: debian
    name: main
    command: ["sleep", "infinity"]
EOF

(dev) $ kubectl exec -ti basic-debian-pod -- /bin/bash

(pod) $ ls /var/run/secrets/kubernetes.io/serviceaccount
ca.crt
namespace
token

Що це за файли? Звідки вони взялися? Вони, звичайно, не схожі на те, що поставляється в базовому образі Debian:

ca.crt — це прив’язка довіри, необхідна для перевірки сертифіката, представленого сервером API Kubernetes у цьому кластері. Як правило, він міститиме один сертифікат, закодований PEM.
простір імен містить простір імен, у якому працює модуль — у нашому випадку default.
token містить маркер облікового запису служби — маркер носія, який можна приєднати до запитів API. Читачі з орлиним оком можуть помітити, що він має контрольну структуру JSON Web Token (JWT):<base64>.<base64>.<base64>.

Відмова від гігієни безпеки: ніде не розміщуйте ці маркери. Це маркери носія, що означає, що будь-хто, хто володіє маркером, має право автентифікуватися як обліковий запис служби вашої програми.

Щоб з’ясувати, звідки беруться ці файли, ми можемо перевірити наш об’єкт pod, як він існує на сервері API:

  (dev) $ kubectl get pods basic-debian-pod -o yaml
apiVersion: v1
kind: Pod
metadata:
  name: basic-debian-pod
  namespace: default
  # Lots of stuff omitted here…
spec:
  serviceAccountName: default
  containers:
  - image: debian
    name: main
    command:
    - sleep
    - infinity
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-g9ggg
      readOnly: true
    # Lots of stuff omitted here…
  volumes:
  - name: default-token-g9ggg
    secret:
    - defaultMode: 420
      secretName: default-token-g9ggg
  # Lots of stuff omitted here…

Сервер API додав… багато чого. Але для нас актуальна частина:

Коли контейнер було заплановано, контролер допуску ввів секретний об’єм у кожен контейнер нашого контейнера.
Секрет містить ключі та дані для кожного файлу, який ми бачили в контейнері.

Розглянемо токен ближче. Ось реальний приклад із кластера, якого більше не існує.

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImtUMHZXUGVVM1dXWEV6d09tTEpieE5iMmZrdm1KZkZBSkFMeXNHQXVFNm8ifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tZzlnZ2ciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImFiNzFmMmIwLWFiY2EtNGJjNy05MDVhLWNjOWIyZDY4MzJjZiIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.UiLY98ETEp5-JmpgxaJyyZcTvw8AkoGvqhifgGJCFC0pJHySDOp9Zoq-ShnFMOA2R__MYbkeS0duCx-hxDu8HIbZfhyFME15yrSvMHZWNUqJ9SKMlHrCLT3JjLBqX4RPHt-K_83fJfp4Qn2E4DtY6CYnsGUbcNUZzXlN7_uxr9o0C2u15X9QAATkZL2tSwAuPJFcuzLWHCPjIgtDmXczRZ72tD-wXM0OK9ElmQAVJCYQlAMGJHMxqfjUQoz3mbHYfOQseMg5TnEflWvctC-TJd0UBmZVKD-F71x_4psS2zMjJ2eVirLPEhmlh3l4jOxb7RNnP2N_EvVVLmfA9YZE5A

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

  {
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "default",
  "kubernetes.io/serviceaccount/secret.name": "default-token-g9ggg",
  "kubernetes.io/serviceaccount/service-account.name": "default",
  "kubernetes.io/serviceaccount/service-account.uid": "ab71f2b0-abca-4bc7-905a-cc9b2d6832cf",
  "sub": "system:serviceaccount:default:default"
}

Розбиваючи їх:

iss («емітент») — це стандартна претензія JWT, призначена для ідентифікації сторони, яка видала JWT. У застарілих токенах Kubernetes він завжди жорстко закодований у рядку «kubernetes/serviceaccount», який технічно відповідає визначенню в RFC , але не дуже корисний.
sub (“subject”) – це стандартне твердження JWT, яке ідентифікує суб’єкт маркера (ваш обліковий запис служби, у цьому випадку). Це стандартне рядкове представлення імені вашого облікового запису служби (також використовується під час посилання на обліковий запис служби в правилах RBAC): system:serviceaccount:<namespace>:<name>. Зауважте, що це технічно не відповідає визначенню в RFC , оскільки це не є ні глобально унікальним, ні унікальним у сфері емітента; два облікові записи служби з однаковим простором імен і назвою, але з двох непов’язаних кластерів матимуть того самого емітента та суб’єкта претензій. Однак на практиці це не велика проблема.
kubernetes.io/serviceaccount/namespace – це претензія, специфічна для Kubernetes; він містить простір імен облікового запису служби.
kubernetes.io/serviceaccount/secret.name — претензія, що стосується Kubernetes; він називає секрет Kubernetes, який містить маркер.
kubernetes.io/serviceaccount/service-account.name — претензія, що стосується Kubernetes; він називає обліковий запис служби.
kubernetes.io/serviceaccount/service-account.uid — претензія, специфічна для Kubernetes; він містить UID облікового запису служби. Ця претензія дозволяє комусь, хто перевіряє маркер, помітити, що обліковий запис служби було видалено, а потім створено заново з тим же ім’ям. Іноді це може бути важливо.

Коли ваша програма спілкується з сервером API у своєму кластері, клієнтська бібліотека Kubernetes завантажує цей JWT із файлової системи контейнера та надсилає його в заголовок авторизації всіх запитів API. Потім API-сервер перевіряє підпис JWT і використовує претензії маркера для визначення ідентичності вашої програми.

Це також працює для автентифікації в інших службах. Наприклад, поширеним шаблоном є налаштування Hashicorp Vault для автентифікації абонентів за допомогою маркерів службового облікового запису з вашого кластера. Щоб спростити завдання довіреної сторони (сервісу, який прагне автентифікувати вас), Kubernetes надає TokenReview API ; повіряюча сторона просто повинна зателефонувати TokenReview, передаючи наданий вами маркер. Повернене значення вказує, чи був токен дійсним; якщо так, то він також містить ім’я користувача вашого облікового запису служби (знову у формі system:serviceaccount:<простір імен>:<ім’я>).

чудово Так у чому ж заковика? Чому я зловісно назвав цей розділ «застарілими» токенами? Застарілі токени мають недоліки:

Застарілі токени не мають терміну дії. Якщо його вкрали, або він зареєструвався у файлі, або закріпився на Github, або заморозився в незашифрованій резервній копії, він залишається небезпечним до кінця часу (або до кінця вашого кластера).
Застарілі токени не мають поняття аудиторії. Якщо ваша програма передає токен службі А, то служба А може просто переслати токен службі Б і видати себе за вашу програму. Навіть якщо ви вважаєте, що сервіс A є надійним і компетентним сьогодні, через пункт 1, маркери, які ви передаєте сервісу A, небезпечні назавжди. Якщо ви колись перестанете довіряти службі A, у вас не буде іншого виходу, окрім як змінити корінь довіри для вашого кластера.
Застарілі маркери поширюються через секретні об’єкти Kubernetes, доступ до яких, як правило, не дуже строго контролюється, а це означає, що вони зазвичай не шифруються в стані спокою чи резервних копіях.
Застарілі токени вимагають додаткових зусиль для інтеграції сторонніх служб; їм, як правило, потрібно явно створювати підтримку для Kubernetes через користувацькі претензії на токени та необхідність перевірки токена за допомогою TokenReview API.

Ці проблеми спонукали до розробки нового формату токенів Kubernetes під назвою прив’язані маркери облікового запису служби.

Прив’язані токени: Kubernetes 1.21 і вище

Запущені в Kubernetes 1.13 і стали форматом за замовчуванням у 1.21, зв’язані маркери вирішують усі обмежені функції застарілих маркерів і багато іншого:

Самі токени набагато складніше вкрасти та використати не за призначенням; вони прив’язані до часу, аудиторії та об’єкта.
Вони використовують стандартизований формат: OpenID Connect (OIDC) із повним виявленням OIDC, що полегшує їх прийняття постачальниками послуг.
Вони безпечніше розподіляються між пакетами за допомогою нового типу спроектованого тому Kubelet.

Давайте дослідимо кожну з цих властивостей по черзі.

Ми повторимо нашу попередню вправу та розберемо зв’язаний токен. Це все ще JWT, але структура претензій змінилася:

  {
 "aud": [
   "foobar.com"
 ],
 "exp": 1636151360,
 "iat": 1636147760,
 "iss": "https://container.googleapis.com/v1/projects/taahm-gke-dev/locations/us-central1-c/clusters/mesh-certs-test2",
 "kubernetes.io": {
   "namespace": "default",
   "pod": {
     "name": "basic-debian-pod-bound-token",
     "uid": "a593ded9-c93d-4ccf-b43f-bf33d2eb7635"
   },
   "serviceaccount": {
     "name": "default",
     "uid": "ab71f2b0-abca-4bc7-905a-cc9b2d6832cf"
   }
 },
 "nbf": 1636147760,
 "sub": "system:serviceaccount:default:default"
}

Прив’язка часу реалізується за допомогою вимог exp («закінчення»), iat («випущено о») і nbf («не раніше»); це стандартизовані заяви JWT. Будь-яка зовнішня служба може використовувати власний годинник для оцінки цих полів і відхилення маркерів, термін дії яких закінчився. Якщо не вказано інше, прив’язані токени за замовчуванням мають одну годину життя. API Kubernetes TokenReview автоматично перевіряє, чи минув термін дії маркера, перш ніж визначити його дійсність.

Прив’язка аудиторії реалізується претензією aud (“аудиторія”); знову ж таки, стандартизована претензія JWT. Аудиторія міцно асоціює токен із певною повірюючою стороною. Наприклад, якщо ви надсилаєте службі A маркер, прив’язаний до рядка «служба A», A більше не зможе пересилати маркер службі B, щоб видати себе за вас. Якщо він спробує, служба B відхилить маркер, оскільки очікує аудиторію «служби B». API Kubernetes TokenReview дозволяє службам визначати аудиторії, які вони приймають під час перевірки маркера.

Прив’язка об’єктів реалізована групою претензій kubernetes.io. Застарілий токен містив лише інформацію про обліковий запис служби, але прив’язаний токен містить інформацію про модуль, якому було видано токен. У цьому випадку ми говоримо, що маркер прив’язаний до модуля (токени також можуть бути прив’язані до секретів). Маркер вважатиметься дійсним, лише якщо модуль все ще присутній і працює відповідно до сервера Kubernetes API — щось на кшталт перезавантаженої версії заяви про закінчення терміну дії. Зовнішнім службам важче перевірити цей тип прив’язки, оскільки вони не мають (а ви не хочете, щоб вони мали) рівень доступу до вашого кластера, необхідний для перевірки умови. На щастя, Kubernetes TokenReview API також підтверджує ці заяви.

Прив’язані маркери облікового запису служби є дійсними маркерами ідентифікації OpenID Connect (OIDC). Це має ряд наслідків, але найбільш значний можна побачити у вартості претензії iss («емітента»). Не всі реалізації Kubernetes підтверджують це твердження, але для тих, які мають (включаючи GKE), воно вказує на дійсну кінцеву точку виявлення OIDC для токенів, випущених кластером. Результатом цього є те, що зовнішнім службам не потрібно знати Kubernetes, щоб автентифікувати клієнтів за допомогою облікових записів служби Kubernetes; їм потрібна лише підтримка OIDC і OIDC Discovery. Як приклад такого типу інтеграції, кінцеві точки OIDC Discovery лежать в основі GKE Workload Identity, яка об’єднує системи ідентифікації Kubernetes і GCP.

Як останнє вдосконалення, прив’язані токени сервісного облікового запису розгортаються на модулях у більш масштабований і безпечний спосіб. У той час як застарілі маркери генеруються один раз для облікового запису служби, зберігаються в секреті та монтуються в модулі через секретний том, прив’язані маркери генеруються на льоту для кожного пакета та вводяться в пакети за допомогою нового типу тому Kubelet serviceAccountToken. Щоб отримати доступ до них, ви додаєте специфікацію тому до свого модуля та монтуєте його в контейнери, яким потрібен маркер.

  (dev) $ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: basic-debian-pod-bound-token
  namespace: default
spec:
  serviceAccountName: default
  containers:
  - image: debian
    name: main
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: my-bound-token
      mountPath: /var/run/secrets/my-bound-token
  volumes:
  - name: my-bound-token
    projected:
      sources:
      - serviceAccountToken:
          path: token
          audience: foobar.com
          expirationSeconds: 3600
EOF

Зауважте, що ми маємо заздалегідь вибрати аудиторію для маркера, а також контролюємо термін дії маркера. Вимоги до аудиторії означають, що досить поширеним є монтування кількох прив’язаних маркерів до одного модуля, по одному для кожної зовнішньої сторони, з якою модуль спілкуватиметься.

Внутрішньо проектований обсяг serviceAccountToken реалізовано безпосередньо в Kubelet (основному хост-агенті Kubernetes). Kubelet обробляє зв’язок із kube-apiserver для запиту відповідного зв’язаного маркера перед запуском модуля та періодично оновлює маркер, коли термін його дії наближається.

Підсумовуючи, пов’язані токени є:

Значно безпечніший, ніж застарілі токени, завдяки прив’язці часу, аудиторії та об’єкта, а також завдяки використанню більш безпечного механізму розповсюдження для модулів.
Завдяки сумісності з OIDC легше використовувати для зовнішніх сторін.

Однак спосіб інтеграції з ними змінився. Оскільки для кожного облікового запису служби був один застарілий маркер, завжди доступний за адресою /var/run/secrets/kubernetes.io/serviceaccount/token, кожен пакет може мати кілька прив’язаних маркерів. Оскільки токени закінчуються та оновлюються Kubelet, програми повинні періодично перезавантажувати їх із файлової системи.

Прив’язані токени були доступні з Kubernetes 1.13, але токен за замовчуванням, виданий для модулів, і надалі залишався застарілим токеном з усіма недоліками безпеки, які випливали з цього. У Kubernetes 1.21 це змінюється: маркером за замовчуванням є прив’язаний маркер облікового запису служби. Kubernetes 1.22 завершує міграцію, просуваючи маркери прив’язаних облікових записів служби за замовчуванням до GA.

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

Вплив на клієнтів

У Kubernetes 1.21 маркер за замовчуванням, доступний на /var/run/secrets/kubernetes.io/serviceaccount/token, змінюється зі старого маркера на маркер зв’язаного облікового запису служби. Якщо ви використовуєте цей маркер як клієнт, надсилаючи його як маркер-носія до API, вам може знадобитися внести зміни у свою програму, щоб вона працювала.

Для клієнтів є дві основні відмінності в новому стандартному маркері:

Новий маркер за замовчуванням має специфічну для кластера аудиторію, яка ідентифікує сервер API кластера. У GKE цією аудиторією є URLhttps://container.googleapis.com/v1/projects/PROJECT/locations/LOCATION/clusters/NAME.
Термін дії нового маркера за замовчуванням періодично закінчується, і його потрібно оновлювати з диска.

Якщо ви коли-небудь використовуєте маркер за замовчуванням лише для зв’язку із сервером API Kubernetes кластера, у якому розгорнуто вашу програму, використовуючи найновіші версії офіційних клієнтських бібліотек Kubernetes (наприклад, за допомогою client-go та rest.InClusterConfig) , то вам не потрібно вносити жодних змін у свою заявку. Маркер за замовчуванням матиме відповідну аудиторію для зв’язку з сервером API, а клієнтські бібліотеки оброблятимуть автоматичне оновлення маркера з диска.

Якщо ваша програма наразі використовує маркер за замовчуванням для автентифікації в зовнішній службі (наприклад, у розгортаннях Hashicorp Vault), вам може знадобитися внести деякі зміни залежно від точного характеру інтеграції між зовнішньою службою та вашим кластером.

По-перше, якщо служба потребує унікальної аудиторії для своїх маркерів доступу, вам потрібно буде змонтувати виділений прив’язаний маркер із правильною аудиторією у ваш модуль і налаштувати програму на використання цього маркера під час автентифікації в службі. Зауважте, що за замовчуванням API Kubernetes TokenReview приймає стандартну аудиторію сервера Kubernetes API, тому, якщо зовнішня служба не вибрала унікальну аудиторію, вона може прийняти маркер за замовчуванням. Це не ідеально з точки зору безпеки — мета претензії аудиторії полягає в тому, щоб захистити себе, гарантуючи, що токени, вкрадені (або використані нею нечесно) зовнішньої служби, не можуть використовуватися для імітації вашої програми в інших зовнішніх службах.

Якщо вам потрібно підключити маркер із виділеною аудиторією, вам потрібно буде створити запланований том serviceAccountToken і підключити його до нового шляху в кожному контейнері, який його потребує. Не намагайтеся замінити маркер за замовчуванням. Потім оновіть код клієнта, щоб прочитати маркер із нового шляху.

По-друге, ви повинні переконатися, що ваша програма періодично перезавантажує маркер з диска. Досить просто опитувати зміни кожні п’ять хвилин і оновлювати конфігурацію автентифікації, якщо маркер змінився. Служби, які надають клієнтські бібліотеки, можуть уже виконувати це завдання у своїх клієнтських бібліотеках.

Давайте розглянемо кілька конкретних сценаріїв:

Ваша програма використовує офіційну клієнтську бібліотеку Kubernetes для читання та запису об’єктів Kubernetes у локальному кластері: переконайтеся, що ваші клієнтські бібліотеки оновлені. Подальші зміни не потрібні; маркер за замовчуванням уже містить правильну аудиторію, а клієнтські бібліотеки автоматично обробляють перезавантаження маркера з диска.

Ваша програма використовує клієнтські бібліотеки Google Cloud і GKE Workload Identity для виклику Google Cloud API: жодних змін не потрібно. Хоча маркери облікового запису служби Kubernetes потрібні у фоновому режимі, усі необхідні обміни маркерами обробляються gke-metadata-server.

Ваша програма використовує маркер облікового запису служби Kubernetes за замовчуванням для автентифікації в Vault: потрібні деякі зміни. Vault інтегрується з вашим кластером, викликаючи Kubernetes TokenReview API, але виконує додаткову перевірку заявки емітента. За замовчуванням Vault очікує застарілого видавця маркера kubernetes/serviceaccountта відхилить новий зв’язаний маркер за умовчанням. Вам потрібно буде оновити конфігурацію сховища, щоб указати нового емітента. На GKE емітент дотримується шаблону .https://container.googleapis.com/v1/projects/PROJECT/locations/LOCATION/clusters/NAME

Наразі Vault не очікує унікальної аудиторії маркера, тому подбайте про захист маркера за умовчанням. Якщо його зламано, його можна використати для отримання ваших секретів із Сховища.

Ваша програма використовує маркер облікового запису служби Kubernetes за замовчуванням для автентифікації в зовнішній службі: загалом не потрібні негайні зміни, окрім того, щоб програма періодично перезавантажувала маркер за замовчуванням із диска. Поведінка Kubernetes TokenReview API за умовчанням гарантує, що автентифікація продовжує працювати під час переходу. З часом зовнішня служба може оновлюватися, вимагаючи унікальної аудиторії для токенів, що вимагатиме від вас монтувати спеціальний зв’язаний токен, як описано вище.

Вплив на послуги

Служби, які автентифікують клієнтів за допомогою маркера облікового запису служби за замовчуванням, продовжуватимуть працювати, коли клієнти оновлять свої кластери до Kubernetes 1.21 через поведінку за замовчуванням Kubernetes TokenReview API. Ваша служба почне отримувати прив’язані токени з аудиторією за замовчуванням, а ваші запити TokenReview за умовчанням перевірятимуть аудиторію за замовчуванням. Однак прив’язані токени відкривають для вас два нових варіанти інтеграції.

По-перше, вам слід погодитися зі своїми клієнтами, щоб почати вимагати унікальну аудиторію для токенів, які ви приймаєте. Це вигідно як вам, так і вашим клієнтам, обмежуючи силу вкрадених токенів:

Вашим клієнтам більше не потрібно довіряти вам токен, який можна використовувати для автентифікації будь-яким третім особам (наприклад, їхнім банкам або платіжним шлюзам).
Вам більше не потрібно хвилюватися про те, що у вас є ці потужні токени, і про потенційну відповідальність за порушення. Натомість прийняті вами маркери можна використовувати лише для автентифікації у вашій службі.

Щоб зробити це, ви повинні спочатку визначити глобально унікальну цінність аудиторії для вашої послуги. Якщо ваша служба доступна за певним іменем DNS, це хороший вибір. Якщо це не вдається, ви завжди можете створити випадковий UUID і використовувати його. Важливо лише, щоб ви та ваші клієнти погодилися щодо вартості.

Після того як ви визначитеся з аудиторією, вам потрібно оновити виклики TokenReview , щоб розпочати перевірку аудиторії. Щоб дати вашим клієнтам час на міграцію, ви повинні провести поетапну міграцію:

Оновіть виклики TokenReview, щоб у spec.audiencesсписку вказати нову аудиторію та аудиторію за замовчуванням. Пам’ятайте, що аудиторія за замовчуванням різна для кожного кластера, тому вам потрібно буде або отримати її від свого клієнта, або вгадати її на основі кінцевої точки kube-apiserver, яку вони вам надають. Нагадуємо, що для кластера GKE аудиторією за замовчуванням є . На цьому етапі ваш сервіс прийматиме як стару, так і нову аудиторію.https://container.googleapis.com/v1/projects/PROJECT/locations/LOCATION/clusters/NAME
Нехай ваші клієнти починають надсилати токени новій аудиторії, монтуючи спеціальний прив’язаний токен у свої модулі та налаштовуючи код клієнта для його використання.
Оновіть свої виклики TokenReview, щоб указати лише нову аудиторію в spec.audiencesсписку.

По-друге, якщо у вас є певні вимоги, ви можете розглянути можливість інтеграції з Kubernetes за допомогою стандарту OpenID Connect Discovery. Якщо екземпляри вашої служби інтегруються з тисячами окремих кластерів, мають підтримувати високі показники автентифікації або мають намір об’єднатися з багатьма джерелами ідентифікації, що не належать до Kubernetes, ви можете розглянути можливість інтеграції з Kubernetes за допомогою стандарту OpenID Connect Discovery, а не Kubernetes TokenReview API .

Цей підхід має переваги та недоліки: Переваги:

Вам не потрібно керувати обліковими даними Kubernetes, щоб ваша служба проходила автентифікацію в кожному об’єднаному кластері (загалом документи OpenID Discovery подаються публічно).
Ваша служба кешуватиме ключі перевірки JWT для об’єднаних кластерів, що дозволить вам автентифікувати клієнтів, навіть якщо kube-apiserver не працює або перевантажений у їхніх кластерах.
Цей кеш також дозволяє вашій службі обробляти вищу швидкість викликів від клієнтів із меншою затримкою, відключаючи об’єднані сервери kube-apiser з критичного шляху для автентифікації.
Підтримка OpenID Connect дає вам можливість об’єднатися з додатковими постачальниками ідентифікаційної інформації за межами кластерів Kubernetes.

Негативні сторони:

Вам потрібно буде керувати кеш-пам’яттю для ключів перевірки JWT для всіх об’єднаних кластерів, включаючи належний термін дії кешованих ключів (кластери можуть змінювати свої ключі без попереднього попередження).
Ви втрачаєте деякі переваги безпеки TokenReview API; зокрема, ви, швидше за все, не зможете перевірити твердження щодо зв’язування об’єктів.

Загалом, якщо TokenReview API можна змусити працювати для вашого випадку використання, вам слід віддати перевагу йому; це набагато простіше в експлуатації та дозволяє уникнути оманливо складної проблеми належної роботи в якості довірчої сторони OpenID Connect.

Бажаєте проконсультуватися чи спробувати щось з сервісів Google? Надсилайте свої запити на info@wiseit.com.ua або залиште повідомлення у чаті на сайті wiseit.com.ua – ми обов’язково зв’яжемось!