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…