如何进行k8s的认证和授权

如何进行k8s的认证和授权，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

发展壮大离不开广大客户长期以来的信赖与支持，我们将始终秉承“诚信为本、服务至上”的服务理念，坚持“二合一”的优良服务模式，真诚服务每家企业，认真做好每个细节，不断完善自我，成就企业，实现共赢。行业涉及成都宣传片制作等，在成都网站建设、成都星空体育app最新版本(2024已更新)建设、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规范。如何进行k8s的认证和授权
  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
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

       当客户端需要认证携带的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",
  "kind": "TokenReview",
  "status": {
    "authenticated": false
  }
}

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
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = dex.example.com
EOF

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的认证和授权
当前地址：/article26/geigcg.html

成都网站建设公司_创新互联，为您提供网页设计公司、网站维护、品牌网站制作、关键词优化、网站内链、静态网站

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

绵阳服务器托管

知识

同城分类信息

2024欧洲杯竞猜官网 | BET体育官方网站（中国）有限公司 | 星空体育·(StarSky Sports) | bet官方（中国）有限公司 | 在线体育竞猜(中国)有限公司 | BET体育|中国有限公司 | bat365在线平台·(中国)官方网站 | 半岛·体育（中国）官方网站 |