关于segmentfault:Kubernetes认证入门指南

Kubernetes用来执行平安拜访和权限的步骤有3个——认证（Authentication）、受权（Authorization）和准入（Admission）。在本文中，咱们先开始理解认证（Authentication）。

在认证中第一个须要思考的是身份认证（Identity）。

身份认证简介

Kubernetes假如“user”是在Kubernetes之外治理的。在生产环境中，能够采纳LDAP（轻量级目录拜访协定）、SSO（单点登录）、Kerberos或SAML（平安断言置标语言）进行身份认证治理。在开发或测试环境中，其余的认证策略也有可能会被应用到。

在Kubernetes中没有表白普通用户的对象，因而不能通过API将普通用户增加到集群中。

认证策略概览

Kubernetes通过认证插件应用认证代理、bearer token、客户端证书或HTTP根本受权来认证API申请。当向API server收回HTTP申请时，插件会尝试将以下属性与申请关联起来：

• Username：辨认最终用户的字符串
• UID：辨认最终用户的字符串，并试图比username格局更为统一，同时每个UID都是独特的。
• Groups：一组字符串，将用户与一组常见的分组用户关联起来
• Extra fields：字符串的映射，保留着受权者认为可能有用的额定信息。

所有这些值对认证零碎来说都是不通明的，只有在authorizer对其进行解释时才有意义。Kubernetes管理员通常会启用多种认证办法。所需的两种最根本的办法是——服务账户的service account token再加上至多一种其余的用户认证办法。

X509客户端证书

• 从Kubernetes 1.4开始，客户端证书能够应用证书组织字段来表明用户的组成员资格。
• 要让一个用户领有多个组成员资格，须要在证书中蕴含多个组织字段。
• 通过向API server传递 --client-ca-file=<FILE>选项来启用客户端证书认证。
• 援用的文件必须蕴含一个或多个证书颁发机构，用于验证提交给API server的客户证书。
• 如果出示客户端证书并进行验证，则应用主体的通用名作为申请的用户名。

例如，应用openssl命令行工具来生成证书签名申请：

openssl req -new -key <pem_file>.pem -out <out-csr-file>.pem -subj "/CN=admin/O=prod/O=dev/O=uat"

这将为用户名admin创立一个CSR（证书签名申请），该用户名属于以下3个组：prod、dev和uat。

动态Token文件

当在命令行中给出--token-auth-file=<FILENAME>选项时，API Server会从文件中读取bearer token。现在，token无限期存在，如果不重启API Server，就无奈更改token列表。Token文件是一个csv文件，至多有3列：token、用户名、user uid，前面可能还会有组名（这是可选的）。

token, user, uid,"prod,dev,uat"

请留神：如果你有超过1个组，该列必须应用双引号。

在申请中放入一个bearer token

当应用来自HTTP客户端的bearer token认证时，API server冀望受权申请头的值为Bearer <Token>。bearer token必须是一个字符序列，能够只需应用HTTP的编码和援用性能就能够将其放在HTTP申请头的值中。例如，如果Bearer Token是ad644f3f-bfch-295b-75bk-h9g8ngf36hb6，那么它将呈现在HTTP申请头中，如下所示：

Authorization: Bearer ad644f3f-bfch-295b-75bk-h9g8ngf36hb6

动态密码文件

通过向API server传递--basic-auth-file=<FILENAME>选项来启用根本认证。当初，根本的认证凭证将无限期地继续上来，而且如果不重新启动 API server，就无奈更改明码。

根本的 auth 文件是一个 csv 文件，至多有 3 列：明码、用户名、用户 ID。在Kubernetes 1.6及当前的版本中，你能够指定一个可选的第4列，蕴含逗号分隔的组名。如果你有多个组，你必须用双引号(")括住第4列的值。

password,user,uid,"group1,group2,group3"

当应用来自HTTP客户端的根本认证时，API server冀望Authorizationheader的值为：

Basic BASE64ENCODED(USER:PASSWORD)

服务账户Token

服务账户是一个主动启用的身份认证器，它应用签名的bearer token来验证申请。该插件须要2个可选的标记：

--service-account-key-file

一个蕴含PEM编码密钥的文件，用于签订bearer token。如果没有指定，将应用API server的TLS密钥。

--service-account-lookip

如果启用了，从API sever上删除的token将被撤销。

服务账户通常由API server主动创立，并通过ServiceAccount 准入控制器与集群中运行的Pod相关联。

Bearer Token会被挂载到家喻户晓的地位的Pod中，并容许集群内过程与API Server对话。账户能够应用PodSpec的serviceAccountName字段与Pod显式关联。

留神，serviceAccountName通常会被省略，因为这是主动实现的。

练习实际：应用ServiceAccount Token

应用以下命令能够创立ServiceAccount：

kubectl create serviceaccount testuser

创立的密钥蕴含API server的公共CA和签名的JSON web Token（JWT）。以下命令能够显示出揭示相干密钥的yaml：

kubectl get serviceaccount testuser -o yaml

以下命令能够显示可用Token：

kubectl get secrets

要取得编码的token数据，请输出：

kubectl get secret testuser-token-mgtnp -o yaml

你能够将编码后的token数据复制并粘贴到https://jwt.io/ 以查看有效载荷。应用你抉择的编辑器输出以下yaml文件（test-pod.yaml），以运行一个pod：

apiVersion: v1 kind: pod metadata:    name: test-pod spec:    serviceAccountName: testuser    container:    - name: alpine:3.7        command:        - "sh"        - "-c"        - "sleep 100"

而后应用以下命令启动pod：

kubectl apply -f test-pod.yaml

应用describe能够查看更具体的内容：

kubectl describe test-pod

当初，咱们有一个正在运行的pod，名为test-pod，让咱们进入交互模式并运行一个shell：

kubectl exec -it test-pod -- sh

如果你想在docker容器内运行shell，所应用的命令与docker命令相似。这时，咱们将会收到一个提醒，而后进入Alpine Linux零碎，该零碎是在pod中的一个容器内运行的。为了关上被复制到容器中的token，你须要运行以下命令：

cat /var/run/sercrets/kubernetes.io/serviceaccount/token

复制输入并将该token粘贴在https://jwt.io/上Encoded局部...

这简直以一种非常直观的形式向你阐明了Kubernetes如何在token中进行身份验证有效载荷。

作者：
Sudip Sengupta
链接：
https://dzone.com/articles/ku...