EKS кластер не предоставляет клиент-ca-файл - PullRequest
Новая
       6

EKS кластер не предоставляет клиент-ca-файл

0 голосов
/ 17 января 2019

Создал кластер в EKS (Kubernetes 1.11.5) с несколькими группами узлов, однако я заметил, что в конфигурационном файле extension-apiserver-authentication отсутствует ключ client-ca-file.

Я предполагаю, что это связано с тем, как инициируется служба API Kubernetes. Кто-нибудь еще сталкивался с этой проблемой?

Я столкнулся с этой проблемой при развертывании диспетчера сертификатов, который запрашивает сервер API с GET https://10.100.0.1:443/api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication.

В GKE это не проблема, поскольку extension-apiserver-authentication configmap уже включает client-ca-file.

extension-apiserver-authentication configmap в AWS, 

apiVersion: v1
data:
  requestheader-allowed-names: '["front-proxy-client"]'
  requestheader-client-ca-file: |
    <certificate file>
  requestheader-extra-headers-prefix: '["X-Remote-Extra-"]'
  requestheader-group-headers: '["X-Remote-Group"]'
  requestheader-username-headers: '["X-Remote-User"]'
kind: ConfigMap
metadata:
  creationTimestamp: 2019-01-14T04:56:51Z
  name: extension-apiserver-authentication
  namespace: kube-system
  resourceVersion: "39"
  selfLink: /api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication
  uid: ce2b6f64-17b8-11e9-a6dd-021a269d3ce8

Однако в GKE, 

apiVersion: v1
data:
  client-ca-file: |
    <client certificate file>
  requestheader-allowed-names: '["aggregator"]'
  requestheader-client-ca-file: |
    <certificate file>
  requestheader-extra-headers-prefix: '["X-Remote-Extra-"]'
  requestheader-group-headers: '["X-Remote-Group"]'
  requestheader-username-headers: '["X-Remote-User"]'
kind: ConfigMap
metadata:
  creationTimestamp: 2018-05-24T12:06:33Z
  name: extension-apiserver-authentication
  namespace: kube-system
  resourceVersion: "32"
  selfLink: /api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication
  uid: e6c0c431-5f4a-11e8-8d8c-42010a9a0191

Ответы [ 2 ]

0 голосов
/ 22 июля 2019

Я также столкнулся с этой проблемой при попытке использовать cert-manager в кластере AWS EKS. Сертификат можно ввести самостоятельно, используя сертификат, полученный из интерфейса командной строки AWS. Для решения этой проблемы выполните следующие действия:

Получить сертификат

Сертификат хранится в кодировке Base64 и может быть получен с помощью 

aws eks describe-cluster \
        --region=${AWS_DEFAULT_REGION} \
        --name=${CLUSTER_NAME} \
        --output=text \
        --query 'cluster.{certificateAuthorityData: certificateAuthority.data}' | base64 -D

Введите сертификат

Редактировать configMap / extension-apiserver-authentication в пространстве имен системы kube: kubectl -n kube-system edit cm extension-apiserver-authentication

В разделе данных добавьте ЦС в новую запись конфигурации с именем client-ca-file. Например: 

  client-ca-file: |
    -----BEGIN CERTIFICATE-----
...
    -----END CERTIFICATE-----
0 голосов
/ 17 января 2019

Ваши предположения могут быть правильными, я имею в виду, что ваша проблема действительно может быть связана с тем, как api-сервер запускается в EKS, и когда отсутствует опция - client-ca-file , в соответствии с исходный код apiserver:

Кластер не предоставляет клиентский ca-файл в configmap /% s в% s, поэтому аутентификация сертификата клиента на расширение api-server не будет работать.

Мне интересно, можете ли вы создать клиент-CA самостоятельно и впоследствии обновить ConfigMap с расширением-apiserver-аутентификацией. В конце концов, в EKS у нас есть доступ к CA (способ получить его здесь ), который может послужить нам для подписи клиентских сертификатов, как описано на странице GitHub с sample api-сервером .

В качестве дополнительного комментария:

Я заметил, что на EKS такие компоненты, как kubelet, используют aws-iam-authenticator (содержимое /var/lib/kubelet/kubeconfig на узле кластера): 

apiVersion: v1
kind: Config
users:
- name: kubelet
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - token
      - -i
      - eks-api-eval
      command: /usr/bin/aws-iam-authenticator
      env: null

напротив GKE, где client-ca используется как способ аутентификации клиентов: 

apiVersion: v1
kind: Config
users:
- name: kubelet
  user:
    client-certificate: /etc/srv/kubernetes/pki/kubelet.crt
    client-key: /etc/srv/kubernetes/pki/kubelet.key
...