Este artigo foi incluído na coluna " Aprenda k8s do zero "
Artigo anterior: Compreensão aprofundada do kubectl Clique pular
Gerenciamento de configuração com rbac
Segredo do Centro de Gerenciamento de Configuração
O que é um Segredo?
O Configmap que aprendemos acima geralmente é usado para armazenar dados de texto simples, como arquivos de configuração. Para alguns dados confidenciais, como senhas, chaves privadas e outros dados, o tipo secreto é usado.
Secret resolve o problema de configuração de dados confidenciais, como senhas, tokens e chaves secretas sem expor esses dados confidenciais a imagens ou especificações de pod. Secret pode ser usado como Volume ou variável de ambiente.
Para usar um segredo, o pod precisa fazer referência ao segredo. Os pods podem usar segredos de duas maneiras: como arquivos em um volume que são montados em um ou mais contêineres no pod ou quando o kubelet extrai imagens para o pod. (Por exemplo, harbour pull, que armazena a senha do usuário do porto, etc.)
Existem três parâmetros opcionais para o segredo:
genérico: Um tipo genérico, normalmente usado para armazenar dados de senha.
tls: Este tipo é usado apenas para armazenar chaves privadas e certificados.
docker-registry: Se você deseja salvar as informações de autenticação do repositório docker, deve usar esse tipo para criar.
Tipo de segredo:
Conta de serviço: costumava ser referenciada por conta de serviço. Quando o serviceaccout for criado, o Kubernetes criará o segredo correspondente por padrão. Se o pod usar serviceaccount, o segredo correspondente será montado automaticamente no diretório /run/secrets/kubernetes.io/serviceaccount do pod.
Opaco: Segredo no formato de codificação base64, usado para armazenar senhas, chaves secretas, etc. Os dados originais podem ser obtidos através da decodificação base64-decode, então a segurança é fraca
kubernetes.io/dockerconfigjson: usado para armazenar informações de autenticação para registro privado do docker.
Usar segredo
1. Introduzir o segredo através de variáveis de ambiente para
criar a senha do usuário root do mysql como segredo
[root@k8smaster ~]# kubectl create secret generic mysql-password --from-literal=password=paopaopodshuaige66
secret/mysql-password created
[root@k8smaster secret]# kubectl get secrets
NAME TYPE DATA AGE
mysql-password Opaque 1 60s
[root@k8smaster secret]# kubectl describe secret mysql-password
Name: mysql-password
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password: 18 bytes
O valor da senha é criptografado, mas a criptografia do segredo é uma pseudo-criptografia, apenas codifica os dados em base 64. Segue-se a descriptografia para encontrar a senha criptografada em mysqlpassword.
[root@k8smaster secret]# kubectl get secret -o yaml
- apiVersion: v1
data:
password: eGlhbmNoYW9wb2QqKmx1Y2t5NjY=
[root@k8smaster secret]# echo 'eGlhbmNoYW9wb2QqKmx1Y2t5NjY=' | base64 --decode
paopaopodshuaige66
#创建 pod，引用 secret
[root@k8smaster secret]# vim pod-secret.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-secret
labels:
app: myapp
spec:
containers:
- name: myapp
image: nginx
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
env:
- name: MYSQL_ROOT_PASSWORD #它是 Pod 启动成功后,Pod 中容器的环境变量名.
valueFrom:
secretKeyRef:
name: mysql-password #这是 secret的对象名 把这个secret中的password这个key和对应的value值赋值给上面的变量
key: password #它是 secret 中的 key 名
[root@k8smaster secret]# kubectl apply -f pod-secret.yaml
pod/pod-secret created
[root@k8smaster secret]# kubectl exec -it pod-secret -- /bin/sh
/ # printenv
MYSQL_ROOT_PASSWORD=paopaopodshuaige66
Monte Segredo via volume
Criar segredo, criptografar manualmente, com base na criptografia base64
[root@k8smaster secret]# echo -n 'admin' | base64
YWRtaW4=
[root@k8smaster secret]# echo -n 'paopaoshuaige' | base64
cGFvcGFvc2h1YWlnZQ==
解码
[root@k8smaster secret]# echo cGFvcGFvc2h1YWlnZQ== | base64 -d
paopaoshuaige
Criar arquivo yaml
[root@k8smaster secret]# vim secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: cGFvcGFvc2h1YWlnZQ==
[root@k8smaster secret]# kubectl apply -f secret.yaml
secret/mysecret created
[root@k8smaster secret]# kubectl describe secret mysecret
Name: mysecret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
password: 13 bytes
username: 5 bytes
Monte o Segredo no Volume
[root@xianchaomaster1 ~]# vim pod_secret_volume.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-secret-volume
spec:
containers:
- name: myapp
image: registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1
imagePullPolicy: IfNotPresent
volumeMounts:
- name: secret-volume
mountPath: /etc/secret
readOnly: true
volumes:
- name: secret-volume #把secret做成卷挂载到/etc/secret 只读权限
secret:
secretName: mysecret
[root@k8smaster secret]# kubectl apply -f pod_secret_volume.yaml
pod/pod-secret-volume created
[root@k8smaster secret]# kubectl exec -it pod-secret-volume -- /bin/sh
/ # ls /etc/secret
password username
/ # cat /etc/secret/username
admin
/ # cat /etc/secret/password
paopaoshuaige/ #
Pode-se ver acima que as informações secretas montadas no pod foram realmente descriptografadas.
Autorização RBAC do mecanismo de segurança k8s
gerenciamento de segurança k8s: uma visão geral da autenticação, autorização e controle de admissão
O k8s fez configurações precisas para autenticação, autorização e controle de acesso de todo o nosso sistema; para o cluster k8s, o apiserver é a única entrada para o controle de acesso de todo o cluster. Quando implantamos aplicativos no cluster k8s, também podemos pass the sink A porta exposta pelo NodePort do host acessa o programa dentro, e o usuário precisa passar pelo seguinte processo de autenticação para acessar o cluster kubernetes: authentication -> autorização -> controle de admissão (adminationcontroller)
1. Autenticação é a autenticação do cliente, e o ponto popular é a autenticação de nome de usuário e senha
2. Autorização é a autorização de recursos. Os recursos no k8s nada mais são do que contêineres. No final, são na verdade os recursos de computação, rede e armazenamento do contêiner. Quando uma solicitação é autenticada, ela precisa acessar um determinado resource (como criar um pod) , a verificação de autorização determinará se o recurso (como um pod em um namespace) está acessível ao cliente de acordo com as regras de autorização.
3. Mecanismo de Controle de Admissão: O Controlador de Admissão está localizado no Servidor API. Antes que o objeto seja persistido, o Controlador de Admissão intercepta a solicitação ao Servidor API, que geralmente é usado para autenticação e autorização. Ele contém dois controladores especiais:
MutatingAdmissionWebhook e ValidatingAdmissionWebhook. Como mutação de configuração e webhook de controle de admissão de validação, respectivamente.
Mutação do controle de admissão: modifique o objeto solicitado
Validando o controle de admissão: validando o objeto solicitado
O controlador de admissão é configurado nos parâmetros de inicialização do API Server. Um controlador de admissão pode pertencer a um ou a ambos os itens acima. Quando a solicitação chega ao API Server, o controle de admissão de alteração é executado primeiro e, em seguida, o controle de admissão de verificação é executado.
Ao implantar um cluster do Kubernetes, habilitaremos uma série de controladores de admissão por padrão. Se esses controladores de admissão não estiverem definidos, pode-se dizer que seu cluster do Kubernetes está executando nu. Somente o administrador do cluster pode modificar o controlador de admissão do cluster.
Por exemplo, eu habilitaria o seguinte controlador de admissão por padrão.
--admission-control=ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota,MutatingAdmissionWebhook,ValidatingAdmissionWebhook
A arquitetura geral do k8s também é uma arquitetura de microsserviços. Todas as requisições são feitas através de um GateWay, ou seja, o componente kube-apiserver (que fornece serviços REST para o mundo externo). Existem dois tipos de clientes no k8s, um é para usuários comuns, e o outro é para usuários comuns. É um Pod no cluster. Os mecanismos de autenticação desses dois clientes são um pouco diferentes, mas não importa qual seja, eles precisam passar pelos três mecanismos de autenticação, autorização, e acesso por sua vez.
Certificação
1. A autenticação suporta uma variedade de plug-ins
(1) Autenticação de token:
Ambas as partes têm uma chave compartilhada e uma senha é criada primeiro no servidor, e o cliente pode efetuar login com essa senha ao efetuar login. Este é o método de autenticação de chave simétrica. O k8s fornece uma interface tranquila e todos os seus serviços são fornecidos por meio do protocolo http, portanto, as informações de autenticação só podem ser passadas pelo cabeçalho de autenticação do protocolo http, que geralmente é chamado de token.
(2) autenticação SSL:
Para acesso k8s, a autenticação SSL permite que o cliente confirme a identidade de autenticação do servidor. Quando nos comunicamos com o servidor, precisamos que o servidor envie um certificado. Precisamos confirmar se o certificado é assinado por ca. Se for um ca reconhecemos Assinado, as informações de assunto nele são consistentes com as informações do host de destino que visitamos, não há problema, então pensamos que a identidade do servidor foi autenticada. O mais importante no k8s é que o servidor também precisa autenticar as informações do cliente, e o kubectl também deve ter um certificado, esse certificado também é um certificado assinado pela ca reconhecida pelo servidor. Ambas as partes precisam autenticar uma a outra para realizar a comunicação criptografada, que é a autenticação ssl.
2. Conta no kubernetes
O cliente inicia uma solicitação ao apiserver. O apiserver precisa identificar se o usuário tem a permissão solicitada e se o usuário pode realizar a operação correspondente por meio do apiserver. Quais informações são necessárias para identificar as informações do usuário para concluir o controle de acesso relevante para o usuário?
kubectl explica pods.spec pode ver que existe um campo serviceAccountName (nome da conta de serviço), esta é a conta usada quando nosso pod se conecta ao apiserver, portanto, existem dois tipos de contas em todo o cluster kubernetes, ServiceAccount (conta de serviço), Conta de usuário (conta de usuário))
Conta de usuário: uma conta na qual todos podem fazer login na realidade, o cliente deseja iniciar uma solicitação ao apiserver, e o apiserver precisa identificar se o cliente possui a permissão solicitada, então usuários diferentes terão permissões diferentes, dependendo do representação da conta do usuário, chamada de nome de usuário
ServiceAccount: foi projetado para facilitar o processo no Pod para chamar a API do Kubernetes ou outros serviços externos. É um recurso no kubernetes
conta sa: a conta usada para fazer login no painel
conta de usuário: Este é o usuário que efetua login na máquina física do k8s
执行kubectl指令的时候会加载文件
[root@k8smaster secret]# cat /root/.kube/config
文件里有一个user用户，做了rbac授权
user: kubernetes-admin
会基于这个用户去访问k8s
escreva no final
Não é fácil de criar, se você acha que o conteúdo é útil para você, por favor me dê um link de três links para me apoiar! Se houver algum erro, por favor, aponte-o nos comentários e eu vou alterá-lo a tempo!
A série atualmente sendo atualizada: Aprendendo k8s do zero
Obrigado por assistir, o artigo está misturado com compreensão pessoal, se houver algum erro, entre em contato comigo para apontar ~