Сервер API: Невозможно аутентифицировать запрос из-за ошибки: неверный токен на предъявителя

Question

Я настроил пример кластера Kubernetes с 3 основными узлами и 2 рабочими узлами. Я попытался подключить его к провайдеру OpenId (в моем случае Keycloak). Но при запросе API я получаю следующее сообщение от kubectl:

error: You must be logged in to the server (Unauthorized)

или через curl:

curl -H "Authorization: Bearer $token" -k https://192.168.178.30:6443/api/v1/namespaces/default/pods
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "Unauthorized",
  "reason": "Unauthorized",
  "code": 401
}

и в логах сервера API написано

Unable to authenticate the request due to an error: invalid bearer token

Согласно jwt.io мой токен действителен.

Конфигурация сервера API

На сервере API я указал следующие параметры:

oidc-issuer-url: https://192.168.178.25:8443/auth/realms/master
oidc-client-id: account
oidc-ca-file: /etc/kubernetes/ssl/keycloak-rootCA.pem
oidc-username-claim: sub
oidc-groups-claim: groups

Мне пришлось указать файл CA, потому что сертификат, используемый для keycloak, был самоподписанным

Сертификат, кажется, работает, потому что скручивание без файла CA приводит к ошибке; где указание файла CA не:

ansible@node1:~$ curl https://192.168.178.25:8443/auth/realms/master
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.


ansible@node1:~$ curl --cacert /etc/kubernetes/ssl/keycloak-rootCA.pem https://192.168.178.25:8443/auth/realms/master
{"realm":"master","public_key":"...","token-service":"https://192.168.178.25:8443/auth/realms/master/protocol/openid-connect","account-service":"https://192.168.178.25:8443/auth/realms/master/account","tokens-not-before":0}

JWT Token

Полезная нагрузка моего токена JWT выглядит следующим образом:

{
  "jti": "455feab7-5828-49f3-9243-a2ce0a1ae6f9",
  "exp": 1557246081,
  "nbf": 0,
  "iat": 1557246021,
  "iss": "https://192.168.178.25:8443/auth/realms/master",
  "aud": "account",
  "sub": "78f9bdc8-d1a4-43c4-ab83-f1b4645519f6",
  "typ": "ID",
  "azp": "account",
  "auth_time": 1557246020,
  "session_state": "ccafaa62-a888-43dd-9135-1c5a31766e0b",
  "acr": "1",
  "email_verified": true,
  "name": "Testuser",
  "groups": [
    "group1",
    "k8s-admin"
  ],
  "preferred_username": "dummy-username",
  "given_name": "Firstname1",
  "family_name": "Lastname1",
  "email": "me@example.com"
}

Когда я пытаюсь войти с помощью токена сгенерированной учетной записи службы (из kubernetes), все работает нормально.

дополнительная информация

Среда была настроена с помощью Kubespray, а параметры сервера API указывались следующим образом:

kube_oidc_url: https://192.168.178.25:8443/auth/realms/master
kube_oidc_client_id: account
kube_oidc_ca_file: "{{ kube_cert_dir }}/keycloak-rootCA.pem"
kube_oidc_username_claim: sub
kube_oidc_groups_claim: groups
#kube_oidc_username_prefix: "oidc:"
#kube_oidc_groups_prefix: "oidc:"

Спасибо за вашу помощь.

Answer 1

Проблема заключалась в том, что Kubespray не перегнал мои настройки в спецификации Pod api-сервера (/etc/kubernetes/manifests/kube-apiserver.yaml).Когда я добавил параметры в спецификации Pod каждого api-сервера (у меня есть настройки с несколькими мастерами), он работал как положено:

- --oidc-issuer-url=https://192.168.178.25:8443/auth/realms/master
- --oidc-client-id=account
- --oidc-username-claim=email
- '--oidc-username-prefix=oidc:'
- --oidc-groups-claim=groups
- '--oidc-groups-prefix=oidc:'
- --oidc-ca-file=/etc/kubernetes/ssl/keycloak-rootCA.pem

Answer 2

Я думаю, что в вашем случае kube_oidc_url должно быть https://192.168.178.25:8443

Также обратите внимание на требование сертификатов CA из документации :

Примечание отребование № 3 выше, требующее подписанного СА сертификата.Если вы развертываете своего собственного поставщика удостоверений (в отличие от одного из облачных поставщиков, таких как Google или Microsoft), вы ДОЛЖНЫ иметь сертификат веб-сервера вашего поставщика удостоверений, подписанный сертификатом с флагом CA, установленным в значение ИСТИНА, даже если он самоподписан.Это происходит из-за того, что реализация клиента TLS GoLang очень строго соответствует стандартам проверки сертификатов.Если у вас нет удобного CA, вы можете использовать этот сценарий из команды CoreOS для создания простого CA и подписанного сертификата и пары ключей.Или вы можете использовать этот аналогичный скрипт, который генерирует сертификаты SHA256 с более длительным сроком службы и большим размером ключа.