Может ли идентификатор клиента Google и секретный ключ клиента использоваться не членом организации? - PullRequest
Новая
       16

Может ли идентификатор клиента Google и секретный ключ клиента использоваться не членом организации?

1 голос
/ 24 апреля 2019

Скажем, у нас есть кластер kubernetes с Google в качестве поставщика OIDC для аутентификации. Каждый разработчик, использующий этот кластер, имеет ~/.kube/config со следующими настройками: 

user:
    auth-provider:
      config:
        client-id: <client-id>
        client-secret: <client-secret>
        id-token: <id-token>
        idp-issuer-url: https://accounts.google.com
        refresh-token: <refresh-token>

Когда разработчик покидает организацию, он удаляется из логина Google, и он не может использовать это ~/.kube/config для доступа к ресурсам kubernetes, поскольку ему потребуется войти в Google, но он не может сделать это сейчас.

Но идентификатор клиента и его секрет все еще просочились.

  • client-secret утечка здесь может быть проблемой безопасности?
  • Может ли он использоваться не членом организации, использующим члена организации?
  • Можно ли использовать client-id и client-secret для создания другого приложения и использовать его для того, чтобы пользователи существующей организации могли войти в систему и получить доступ к ID-токену от имени этого существующего пользователя?

Пожалуйста, предложите.

PS: типом этого идентификатора клиента и секрета клиента является «Другой», а не «Веб-приложение» с URL-адресом перенаправления.

1 Ответ

0 голосов
/ 17 июня 2019

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

Поток OpenID в Kubernetes:

  1. Войдите в систему вашего провайдера идентификации
  2. Ваш провайдер идентификации предоставит вам access_token, id_token и refresh_token
  3. При использовании kubectl используйте ваш id_token с -флаг или добавьте его непосредственно в kubeconfig
  4. kubectl отправляет ваш id_token в заголовке с именем Авторизация на сервер API
  5. Сервер API проверяет правильность подписи JWT, проверяя соответствиесертификат, указанный в конфигурации
  6. Убедитесь, что срок действия id_token не истек
  7. Убедитесь, что пользователь авторизован
  8. После авторизации сервер API возвращает ответ на kubectl
  9. kubectl обеспечивает обратную связь с пользователем

Для вас наиболее важными моментами являются 5 , 6 , 7 .JWT вашего клиента недействителен, поэтому пользователи, которые покидают работу и его учетные данные (или члены другой организации, имеющие такие учетные данные), не могут получить доступ к вашему кластеру.

Идентификатор id_token не может быть отозван, это как сертификат, поэтому он должен быть недолговечным.Нет простого способа пройти проверку подлинности на панели мониторинга Kubernetes без использования прокси-команды kubectl или обратного прокси-сервера, который вводит id_token.

Дополнительные сведения можно найти здесь: kubernetes-cluster-access .Таким образом, при условии, что вам не нужно беспокоиться об утечке client_id и

, вы также можете удалить записи кластера / контекста / пользователя, например:

$ kubectl config unset users.gke_project_zone_name

Client_secret isтеперь необязателен для конфигурации oidc k8s, что означает, что он может поддерживать общедоступных клиентов (с или без client_secret) и конфиденциальных клиентов (с client_secret, для каждого пользователя kubectl).

Таким образом, ответ на каждый вопрос - нет,Не нужно беспокоиться о безопасности.

Надеюсь, это поможет.

...