Пользовательский SSL-сертификат в кластере kubernetes на AWS с использованием копов, ошибка аутентификации - PullRequest
Новая
       33

Пользовательский SSL-сертификат в кластере kubernetes на AWS с использованием копов, ошибка аутентификации

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

Я развертываю кластер kubernetes в AWS, используя kops, используя следующий скрипт bash: 

#! /bin/bash
export NODE_SIZE=${NODE_SIZE:-t2.micro}
export MASTER_SIZE=${MASTER_SIZE:-t2.small}
export ZONES=${ZONES:-"eu-west-1a,eu-west-1b,eu-west-1c"}
export MASTER_ZONE=${ZONES:-"eu-west-1a"}
export KOPS_STATE_STORE="s3://cluster-state"
export KOPS_DNS_NAME="demo.kubernetes.com"
export NAME="demo.kubernetes.com"
export SSL_CERTIFICATE_ARN="arn:aws:acm:eu-east-1:204911192323:certificate/5e1337bf-f92b-4ccb-9d9e-8197f8782de2"
kops create cluster \
--name=$NAME \
--node-count=3 \
--master-zones eu-west-1a \
--master-count 1 \
--node-size $NODE_SIZE \
--master-size $MASTER_SIZE \
--zones $ZONES \
--topology private \
--dns-zone $KOPS_DNS_NAME \
--networking calico \
--bastion="true" \
--ssh-public-key ./ssh-keys/id_rsa.pub \
--ssh-access 215.138.19.90/32,215.159.102.92/32 \
--admin-access 215.138.19.90/32,215.159.102.92/32 \
--network-cidr 10.10.0.0/16 \
--target=terraform \
--api-ssl-certificate $SSL_CERTIFICATE_ARN \
--image "099720109477/ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-20190406" \
--out=.

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

CLUSTERNAME=demo.kubernetes.com
NAMESPACE=development
USERNAME=asim
GROUPNAME=admin
AWS_PROFILE=demo

# Download CA key and Crts
aws s3 sync s3://${CLUSTERNAME}-state/${CLUSTERNAME}/pki/private/ca/ ca-key --profile ${AWS_PROFILE}

aws s3 sync s3://${CLUSTERNAME}-state/${CLUSTERNAME}/pki/issued/ca/ ca-crt --profile ${AWS_PROFILE}

# Move the key and crt to the current directory
mv ca-key/*.key ca.key
mv ca-crt/*.crt ca.crt

# Generate private key for user
openssl genrsa -out ${USERNAME}.key 2048

CSR_FILE=$USERNAME.csr
KEY_FILE=$USERNAME.key

openssl req -new -key $KEY_FILE -out $CSR_FILE -subj "/CN=$USERNAME/O=$GROUPNAME"

openssl x509 -req -in $CSR_FILE -CA ca.crt -CAkey ca.key -CAcreateserial -out ${USERNAME}.crt -days 10000


CRT_FILE=$USERNAME.crt

cat <<EOF | kubectl create -f -
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: admin-user
  namespace: $NAMESPACE
subjects:
- kind: User
  name: $USERNAME
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF

kubectl config set-credentials $USERNAME \
  --client-certificate=$(pwd)/$CRT_FILE \
  --client-key=$(pwd)/$KEY_FILE

kubectl config set-context $USERNAME-$CLUSTERNAME-context --cluster=$CLUSTERNAME --namespace=$NAMESPACE --user=$USERNAME

Когда я изменяю контекст на вновь созданный контекст для пользователя, я получаю следующую ошибку: 

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

Я выполнил некоторые действия по устранению неполадок и обнаружил, что если я не использую собственный сертификат CA во время создания кластера и удаляю опцию kops --api-ssl-Certificate, я могу создавать пользователей, и они работают нормально, однако если я тогда обновить кластер и начать использовать правильный сертификат CA вместо самозаверяющего сертификата. Я снова получаю сообщение об ошибке. Для меня важно, чтобы я использовал собственные сертификаты на уровне ELB, поэтому при обращении к серверу API через браузер мы не получаем предупреждения безопасности, поскольку это будет производственный кластер. Однако я не могу найти документацию, в которой рассказывается, как создавать пользователей, сохраняя при этом этот пользовательский сертификат на уровне ELB? Есть ли что-то, чего мне не хватает, любая помощь будет высоко оценена.

1 Ответ

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

Я думаю, что ваша проблема проистекает из имени группы, которая в контексте клиентских сертификатов X509 отображается в поле организации сертификата (/O).

Пожалуйста, попробуйте изменить группу 'admin'имя встроенному: 'system:masters'

...