如何进行k8s的认证和授权
如何进行k8s的认证和授权,很多新手对此不是很清楚,为了帮助大家解决这个难题,下面小编将为大家详细讲解,有这方面需求的人可以来学习下,希望你能有所收获。
发展壮大离不开广大客户长期以来的信赖与支持,我们将始终秉承“诚信为本、服务至上”的服务理念,坚持“二合一”的优良服务模式,真诚服务每家企业,认真做好每个细节,不断完善自我,成就企业,实现共赢。行业涉及成都宣传片制作等,在成都网站建设、成都营销网站建设、WAP手机网站、VI设计、软件开发等项目上具有丰富的设计经验。
一、概述
Kubernetes只负责管理Service账户,不管理普通用户的账户。Kubernetes没有代表普通用户帐户的对象。 普通用户信息无法通过API添加到集群。普通用户由外部独立服务管理。K8s通过authentication插件来实现用户认证。K8s本身不管理用户,也不会提供token。
二、k8s支持的认证类型
K8s支持X509 Client证书、token、basic auth认证等。
X509 Client证书:
启动API Server时通过--client-ca-file=SOMEFILE选项提供给API Server。
静态token文件:
1)启动API Server时通过--token-auth-file=SOMEFILE选项提供给API Server。
token文件是csv文件,包含如下内容:
token,user,uid,"group1,group2,group3"
2)通过在http header中提供token信息以完成认证
Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
31ada4fd-adec-460c-809a-9e56ceb75269为具体的token值。
Bootstrap Token
相比于静态token而言,此类token可动态管理。
basic auth:
1)需要将包含password、username、uid、group等信息的csv文件通过--basic-auth-file=SOMEFILE选项提供给API Server,在API Server启动时加载。
2) 需要在http的header中填写Authorization头,其中包含“USER:PASSWORD”的Base64编码后的字符串。
OpenID Connect Token:
采用OAuth3令牌响应的id_token(而不是access_token)作为承载令牌。
需要首先向身份提供商进行身份验证。然后采用身份提供商给你的id_token访问K8s。在Header中添加:Authorization: Bearer XXXXXXX
要使用该认证方式,需要配置API Server:
--oidc-issuer-url 身份提供商的URL,如:https://accounts.google.com,必选
--oidc-client-id 客户端标识,如:kubernetes ,必选
其他可选参数参见:https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens
身份提供商需要支持OpenID Connect规范。
webhook Token认证:
集群中需要配置如下两个参数:
--authentication-token-webhook-config-file 用于配置remote service(负责认证)的文件
--authentication-token-webhook-cache-ttl 用于配置身份认证结果的缓存时间,默认2分钟
webhook采用kubeconfig文件格式进行配置,文件中clusters是指remote service,而users是指API服务器webhook,如下示例:
# Kubernetes API version # users refers to the API server's webhook configuration. # kubeconfig files require a context. Provide one for the API server. |
当客户端需要认证携带的token时,authentication webhook向remote service POSTs一个 JSON格式的authentication.k8s.io/v1beta1 TokenReview对象,如下示例:
{ "apiVersion": "authentication.k8s.io/v1beta1", "kind": "TokenReview", "spec": { "token": "(BEARERTOKEN)" } } |
remote service需要解析上述json,并对token进行校验,然后通过response填写校验结果,成功的response如下示例,且http code必须是2XX:
{ "apiVersion": "authentication.k8s.io/v1beta1", "kind": "TokenReview", "status": { "authenticated": true, "user": { "username": "janedoe@example.com", "uid": "42", "groups": [ "developers", "qa" ], "extra": { "extrafield1": [ "extravalue1", "extravalue2" ] } } } } |
失败的response如下示例:
{ "apiVersion": "authentication.k8s.io/v1beta1", |
Authenticating Proxy:
API服务器可以根据header values配置来识别users ,如X-Remote-User。
在API Service启动时进行相关配置,指明http的header中哪些key代表用户名、哪些代表用户的group等,如下示例:
--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-
如果发送请求如下:
GET / HTTP/1.1
X-Remote-User: fido
X-Remote-Group: dogs
X-Remote-Group: dachshunds
X-Remote-Extra-Acme.com%2Fproject: some-project
X-Remote-Extra-Scopes: openid
X-Remote-Extra-Scopes: profile
将产生如下用户信息:
name: fido
groups:
- dogs
- dachshunds
extra:
acme.com/project:
- some-project
scopes:
- openid
- profile
为了防止header欺骗,Authenticating Proxy需要在检查请求header之前,向API服务器提交有效的客户端证书,以针对指定的CA进行验证。
–requestheader-client-ca-file 必选, PEM-encoded的证书包。在为用户名检查请求header之前,必须根据指定文件中的证书颁发机构呈现和验证有效的客户端证书。
–requestheader-allowed-names 可选,(common names)通用名称(cn)List。如果设置,则在检查请求header用户名之前,必须提交List中指定(common names)通用名中有效的客户端证书。
CA证书生成脚本:
#!/bin/bash mkdir -p ssl cat << EOF > ssl/req.cnf |
openssl genrsa -out ssl/ca-key.pem 2048
openssl req -x509 -new -nodes -key ssl/ca-key.pem -days 10 -out ssl/ca.pem -subj "/CN=kube-ca"
openssl genrsa -out ssl/key.pem 2048
openssl req -new -key ssl/key.pem -out ssl/csr.pem -subj "/CN=kube-ca" -config ssl/req.cnf
openssl x509 -req -in ssl/csr.pem -CA ssl/ca.pem -CAkey ssl/ca-key.pem -CAcreateserial -out ssl/cert.pem -days 10 -extensions v3_req -extfile ssl/req.cnf
三、K8s双向认证
k8s双向认证时,客户端证书的O={group},CN={username}
webhook方式下,k8s收到客户端证书解析group和username,与webhook插件进行交互对用户及权限进行认证
客户端kubeconfig只需要在users下配置客户端证书和私钥文件:
client-certificate
client-key
embed-certs=true
注:接入CISM时填写group和username、选择CA根证书文件,VNFM服务端自动生成客户端证书和秘钥文件,动态修改kubeconfig配置文件
或直接选择客户端证书,这种场景下需要事先确定VNFM使用的用户名和对应的group,先制作客户端证书,建议采用这种方式。界面上不需要用户填写group和username
webhook token认证:
从webhook的组件获取token
在header中带给k8s
k8s和webhook通讯对token进行认证
webhook返回认证结果(用户名、组、额外信息)
服务端开启--authentication-token-webhook-config-file和--authentication-token-webhook-cache-ttl
# Kubernetes API version
apiVersion: v1
# kind of the API object
kind: Config
# clusters refers to the remote service.
clusters:
- name: name-of-remote-authn-service
cluster:
certificate-authority: /path/to/ca.pem # CA for verifying the remote service.
server: https://authn.example.com/authenticate # URL of remote service to query. Must use 'https'.
# users refers to the API server's webhook configuration.
users:
- name: name-of-api-server
user:
client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
client-key: /path/to/key.pem # key matching the cert
# kubeconfig files require a context. Provide one for the API server.
current-context: webhook
contexts:
- context:
cluster: name-of-remote-authn-service
user: name-of-api-sever
name: webhook
webhook授权:
服务端开启--authorization-webhook-config-file
# Kubernetes API version
apiVersion: v1
# kind of the API object
kind: Config
# clusters refers to the remote service.
clusters:
- name: name-of-remote-authz-service
cluster:
# CA for verifying the remote service.
certificate-authority: /path/to/ca.pem
# URL of remote service to query. Must use 'https'. May not include parameters.
server: https://authz.example.com/authorize
# users refers to the API Server's webhook configuration.
users:
- name: name-of-api-server
user:
client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
client-key: /path/to/key.pem # key matching the cert
# kubeconfig files require a context. Provide one for the API Server.
current-context: webhook
contexts:
- context:
cluster: name-of-remote-authz-service
user: name-of-api-server
name: webhook
双向认证和token可以并存,如下:
user 定义用于向 kubernetes 集群进行身份验证的客户端凭据。
可用凭证有 client-certificate、client-key、token 和 username/password以及embed-certs。
username/password 和 token 是二者只能选择一个,但 client-certificate 和 client-key 可以分别与它们组合。
可以使用 kubectl config set-credentials 添加或者修改 user 条目。
--embed-certs=true:将 ca.pem 和 admin.pem 证书内容嵌入到生成的 kubectl.kubeconfig 文件中(不加时,写入的是证书文件路径);
helm方式访问k8s时,如果要支持token,需要在kubeconfig中设置token,如果token动态获取,则需要定时修改kubeconfig文件。
kubeconfig例子:
apiVersion: v1
clusters:
- cluster:
certificate-authority: fake-ca-file
server: https://1.2.3.4
name: development
- cluster:
insecure-skip-tls-verify: true
server: https://5.6.7.8
name: scratch
contexts:
- context:
cluster: development
namespace: frontend
user: developer
name: dev-frontend
- context:
cluster: development
namespace: storage
user: developer
name: dev-storage
- context:
cluster: scratch
namespace: default
user: experimenter
name: exp-scratch
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
user:
client-certificate: fake-cert-file
client-key: fake-key-file
- name: experimenter
user:
password: some-password
username: exp
其中certificate-authority、client-certificate、client-key是证书和秘钥文件的路径,如果使用BASE64加密后的数据,则需要采用下面的代替:
certificate-authority-data, client-certificate-data, client-key-data
看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注创新互联行业资讯频道,感谢您对创新互联的支持。
本文名称:如何进行k8s的认证和授权
当前URL:http://myzitong.com/article/geigcg.html