devbox
很楠不爱3
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

Kubernetes API Server 认证机制_token-auth-file

作者：很楠不爱3 | 2024-05-16 12:46:41

赞

踩

token-auth-file

认证

开启 TLS时，所有的请求都需要首先认证。Kubernetes支持多种认证机制，并支持同时开启多个认证插件（只要有一个认证通过即可）。

如果认证成功，则用户的 username 会传入授权模块做进一步授权验证，而对于认证失败的请求则返回 HTTP 401。

当apiserver启动的时候，其实有两个和安全相关的配置，一个叫insecure-port，一个叫secure-port，早期大家很习惯的将insecure-port打开，经过insecure-port端口所有的请求其实是没有做任何的安全校验的，也就是认证，鉴权这些逻辑是不走的，这样就面临着一个危险，所有的request是没有认证的，不管是谁发的，它有没有权限，它都会被接受，这很可能就会有一些恶意的请求。

所以现在在非生产环境也会将insecure端口关掉。

另外一个是secure port，secure-port设置之后所有的认证，鉴权这些逻辑都要走。

  1. [root@k8s-master cfg]# vim kube-apiserver.conf 
  2. --secure-port=6443 \

认证插件

针对开放式的框架，它一定会支持很多很多的认证方式。

X509 证书

  • 使用X509客户端证书只需要 API Server启动时配置--client-ca-file=SOMEFILE。在证书认证时，其CN 域用作用户名，而组织机构域则用作 group 名。

证书一般会有key和cert，cert在签发的时候是发给什么机构，哪个人的。这样你带着一个证书来访问apiserver的时候，它有签发你证书的ca文件，它就能够解析出来你的certificates，它就能够知道你是谁。

CN 是请求用户的用户名  O:是请求用户的组名

  1. cat > ca-csr.json <<EOF
  2. {
  3.   "CN": "Kubernetes",
  4.   "key": {
  5.     "algo": "rsa",
  6.     "size": 2048
  7.   },
  8.   "names": [
  9.     {
  10.       "C": "CN",
  11.       "L": "China",
  12.       "O": "Kubernetes",
  13.       "OU": "CA",
  14.       "ST": "Zhejiang"
  15.     }
  16.   ]
  17. }
  18. EOF

静态Token 文件

  • 使用静态 Token 文件认证只需要 API Server启动时配置--token-auth-file=SOMEFILE。
  • 该文件为 csv格式，每行至少包括三列 token，username，userid，token,user,uid,"group1,group2,group3"

apiserver启动的时候要配置一个token-auth-file，在这个csv文件里面配置用户名，用户id，以及对应的token，和用户属于哪些组配置在这个scv文件里面，它有点像简化的数据库，其实也即是将用户名和对应的token发到这里面，然后在apiserver启动的时候加载这个文件，那apiserver就知道我这个集群可以接受哪些用户请求，你带着用户token过来，它就能够判断这个token是不是合法的，如果合法就知道对应的user是谁，它就可以将这个请求接受掉了。

  • 为了支持平滑地启动引导新的集群，Kubernetes 包含了一种动态管理的持有者令牌类型，称作启动引导令牌（Bootstrap Token）。
  • 这些令牌以 Secret 的形式保存在kube-system名字空间中，可以被动态管理和创建。
  • 控制器管理器包含的 TokenCleaner控制器能够在启动引导令牌过期时将其删除。
  • 在使用kubeadm 部署Kubernetes 时，可通过 kubeadm token list 命令查询。

在k8s启动的时候有bootstrap token，它也是可以做认证的。

静态密码文件

  • 需要API Server 启动时配置--basic-auth-file=SOMEFILE，文件格式为cSV，每行至少三列 password，user，uid，后面是可选的group名 password，user，uid，"group1，group2，group3"。(和静态token类似，只不过文件里面存放着密码)

OpenID 

OAuth 2.0的认证机制

ServiceAccount

ServiceAccount是 Kubernetes 自动生成的，并会自动挂载到容器的/run/secrets/kubernetes.io/serviceaccount 目录中。

当你去建立任何的namespace的时候，k8s就有一个控制器，它看见namespace创建了，它就会去建立sa，它会生成token，这个token签发的内容其实就是代表了这个token签发给哪个namespace的，哪个serviceaccount的，这个token是apiserver签发的，所以你带着token去访问apiserver的时候，它就知道这个token合法还是非法，代表的是哪个namespace，哪个serviceaccount。

静态token 示例

https://github.com/cncamp

https://github.com/cncamp/101/tree/master/module6/basic-auth

  1. [root@master ~]# mkdir -p /etc/kubernetes/auth
  2.  
  3. [root@master auth]# cat static-token
  4. cncamp-token,cncamp,1000,"group1,group2,group3"

在这个scv文件里面创建了用户，token叫做cncamp-token，这个是用户的token。用户名是cncamp，它的uid是1000，然后它放到3个group里面，这就是简单的token文件。

如果我们要去启用静态的token，那么我要去修改apiserver的配置文件，这个就是告诉apiserver说，这个文件里面的内容我是承认的。也即是将主机的文件mount到apiserver的pod里面。

在这个pod的volumes里面定义了一个hostpath的volume

更新完apiserver的yaml文件会去做个重启，如果get pod成功那么说明api-server重启成功。

这里面加了header，这个header加了token，这个token代表了cncamp这个用户，直接发rest

api调用通过curl命令。

  1. [root@master manifests]# curl https://192.168.111.8:6443/api/v1/namespaces/default -H "Authorization: Bearer cncamp-token" -k
  2. {
  3.   "kind": "Status",
  4.   "apiVersion": "v1",
  5.   "metadata": {
  6.     
  7.   },
  8.   "status": "Failure",
  9.   "message": "namespaces \"default\" is forbidden: User \"cncamp\" cannot get resource \"namespaces\" in API group \"\" in the namespace \"default\"",
  10.   "reason": "Forbidden",
  11.   "details": {
  12.     "name": "default",
  13.     "kind": "namespaces"
  14.   },
  15.   "code": 403
  1.   volumes:
  2.   - hostPath:
  3.       path: /etc/kubernetes/auth
  4.       type: DirectoryOrCreate
  5.     name: auth-files
  6.  
  7.     - mountPath: /etc/kubernetes/auth
  8.       name: auth-files 
  9.       readOnly: true
  10.  
  11.     - --token-auth-file=/etc/kubernetes/auth/static-token

可以看到由于权限的问题，它的code是403是鉴权不过的，其实认证是通过的，因为它知道你的token对应的用户是cncamp。

  1. [root@master manifests]# curl https://192.168.111.8:6443/api/v1/namespaces/default -H "Authorization: Bearer cncamp-token" -k
  2. {
  3.   "kind": "Status",
  4.   "apiVersion": "v1",
  5.   "metadata": {
  6.     
  7.   },
  8.   "status": "Failure",
  9.   "message": "namespaces \"default\" is forbidden: User \"cncamp\" cannot get resource \"namespaces\" in API group \"\" in the namespace \"default\"",
  10.   "reason": "Forbidden",
  11.   "details": {
  12.     "name": "default",
  13.     "kind": "namespaces"
  14.   },
  15.   "code": 403

也就是说带着cncamp的token去访问apiserver，它已经去本地的static token file里面去校验token代表哪个用户了，它查找到了这个用户并且说这个用户没有权限，其实整个的认证就已经过了。

x509证书

如果能够使用kubernetes自己的ca去签发X509证书，那么它是直接可以认的。 

   - --client-ca-file=/etc/kubernetes/pki/ca.crt

kubeadm搭建的集群，本身就使用了x509证书

ServiceAccount

当创建任何的serviceaccount的时候，在这个namespace里面，其实k8s会自动的在这个namspace里面创建一个叫default的serviceaccount，所谓的serviceaccount就是系统账号。

每个系统账号会有对应的secret，可以看到有ca文件，还有namespace，这个是base64加密了的，还有一个token，这个其实就是apiserver签发的jwt token，和之前静态token是类似的。

可以看到只要带着这个token去访问apiserver，apiserver就能够认出我是谁，配合权限控制那么就可以根据这个token去访问apiserver里面的任何对象。

如果基于内置的认证方式还不能满足你需求，公司有自己的认证系统，认证方式都在集群之外，那么怎么使得k8s集群和这些认证平台去集成，那么就需要通过webhook，k8s认证也支持webhook。

你可以基于webhook来配置来指向外部的认证服务器，有了这种认证集成的方式之后，那么k8s就可以和任何平台去做集成。

Webhook 令牌身份认证

  • --authentication-token-webhook-config-file  指向一个配置文件，其中描述如何访问远程的Webhook服务。
  • --authentication-token-webhook-cache-ttl   用来设定身份认证决定的缓存时间。默认时长为2分钟。

匿名请求

  • 如果使用AlwaysAllow 以外的认证模式，则匿名请求默认开启，但可用--anonymouSs-auth=false禁止匿名请求。

 

Kubernetes API准备工作

创建一个NS名称空间， 专用于运行Pod；

kubectl create ns jenkins

 创建一个secret关联serviceaccount和role，操作K8s API

  1. # 创建role
  2. kubectl -n jenkins create role jenkinsadmin \
  3. --verb=create,delete,update,list,get,patch \
  4. --resource=pods
  5.  
  6. # 创建服务账户
  7. kubectl -n jenkins create serviceaccount jenkinsadmin
  8.  
  9. # 创建角色绑定
  10. kubectl -n jenkins create rolebinding jenkinsadmin --role=jenkinsadmin --serviceaccount=jenkins:jenkinsadmin
  11.  
  12. # 创建secret
  13. kubectl apply -f - <<EOF
  14. apiVersion: v1
  15. kind: Secret
  16. metadata:
  17.   name: jenkinsadmin-token
  18.   namespace: jenkins
  19.   annotations:
  20.     kubernetes.io/service-account.name: jenkinsadmin
  21. type: kubernetes.io/service-account-token
  22. EOF
  23.  
  24.  
  25. while ! kubectl -n jenkins describe secret jenkinsadmin-token | grep -E '^token' >/dev/null; do
  26.   echo "waiting for token..." >&2
  27.   sleep 1
  28. done
  29.  
  30.  
  31. # 获取令牌
  32. TOKEN=$(kubectl -n jenkins get secret jenkinsadmin-token -o jsonpath='{.data.token}' | base64 --decode)
  33.  
  34. echo $TOKEN
  35.  
  36. # 获取API
  37. kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'
  38.  
  39. # 使用令牌玩转 API
  40. curl -X GET https://127.0.0.1:35659/api --header "Authorization: Bearer $TOKEN" --insecure
  1. [root@192 ~]# curl -X GET https://127.0.0.1:6443/api --header "Authorization: Bearer $TOKEN" --insecure
  2. {
  3.   "kind": "APIVersions",
  4.   "versions": [
  5.     "v1"
  6.   ],
  7.   "serverAddressByClientCIDRs": [
  8.     {
  9.       "clientCIDR": "0.0.0.0/0",
  10.       "serverAddress": "192.168.11.134:6443"
  11.     }
  12.   ]
  13. }

将token 以secret text类型存储到Jenkins

POD API

  1. //删除POD
  2. def DeletePod(namespace, podName){
  3.     withCredentials([string(credentialsId: 'f66733bf-ef35-402d-87d1-a79510387d2b', variable: 'CICDTOKEN')]) {
  4.         sh """
  5.            curl --location --request DELETE "https://192.168.1.200:6443/api/v1/namespaces/${namespace}/pods/${podName}" \
  6.            --header "Authorization: Bearer ${CICDTOKEN}" \
  7.            --insecure >/dev/null
  8.         """
  9.     }
  10. }
  11.  
  12. // 创建POD
  13. def CreatePod(namespace, podYaml){
  14.     withCredentials([string(credentialsId: 'f66733bf-ef35-402d-87d1-a79510387d2b', variable: 'CICDTOKEN')]) {
  15.         sh """
  16.            curl --location --request POST "https://192.168.1.200:6443/api/v1/namespaces/${namespace}/pods" \
  17.            --header 'Content-Type: application/yaml' \
  18.            --header "Authorization: Bearer ${CICDTOKEN}" \
  19.            --data "${podYaml}" --insecure >/dev/null
  20.         """
  21.     }
  22. }
  1. curl --location --request POST "https://192.168.11.134:6443/api/v1/namespaces/jenkins/pods" \
  2. --header 'Content-Type: application/yaml' \
  3. --header "Authorization: Bearer ${TOKEN}" \
  4. --data "${podYaml}" --insecure >/dev/null
  5.  
  6. curl --location --request DELETE "https://192.168.11.134:6443/api/v1/namespaces/jenkins/pods/nginx" \
  7. --header "Authorization: Bearer ${TOKEN}" \
  8. --insecure >/dev/null

  1. curl --location --request GET 'https://192.168.11.134:6443/api/v1/namespaces/jenkins/pods' \
  2. --header 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjBqSWxfOExtSW1pVmpKVkFUVGFQbHp1ZE5TcFo0SjlmOUtjMWFveWtrZGMifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJqZW5raW5zIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImplbmtpbnNhZG1pbi10b2tlbi1jbTRsNyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJqZW5raW5zYWRtaW4iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJjMDAwZTVhMC00Yzg0LTQyZWEtYmJiNy1mZmM5MDBhYzUyMjIiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6amVua2luczpqZW5raW5zYWRtaW4ifQ.A-InywzLZZfwx_4-Na9iDDRGsIH0Bjm9Xk92VxKsnP7hflEbOU631EU0eHnewgg0UqAD1kkhW39XupN13oTXrOjHrzWdm_UUMe2cBIYCZD19VIpNnRZ6bBLZ3LFHA2F0gXO14HaVZiUvSYBXgIfyHydetIFQFBPWFtU7091u5iB4pcw_gE-VzGjX6NDHj-81j6Ap2Qr0gIrNvrPVAOpPO9uCSg3PNCgvQMq2ZNrY2te1w7QxmeFPEpOIPiK6VbUkRjhQlHmawULZFol2k5Wwv9z0m1hPQcc2Nten1f1__GR39hUjryWXfltJ8OLpbKWK-AtfBkHx8VqbiKH1vQOrRg' \
  3. --header 'Content-Type: text/plain' \
  4. --data-raw 'abc'

这里请求方法由get换成了delete

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/很楠不爱3/article/detail/578799
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号