访问控制

Kubernetes提供了多种访问控制机制,包括用户认证、授权以及准入控制等。

认证

开启TLS时,所有的请求都需要首先认证。Kubernetes支持多种认证机制,并支持同时开启多个认证插件(只要有一个认证通过即可)。如果认证成功,则用户的username会传入授权模块做进一步授权验证;而对于认证失败的请求则返回HTTP 401。

[warning] Kubernetes不管理用户

虽然Kubernetes认证和授权用到了username,但Kubernetes并不直接管理用户,不能创建user对象, 也不存储username。但是Kubernetes提供了Service Account,用来与API交互。

目前,Kubernetes支持以下认证插件:

  • X509证书
  • 静态Token文件
  • 引导Token
  • 静态密码文件
  • Service Account
  • OpenID
  • Webhook
  • 认证代理
  • OpenStack Keystone密码

X509证书

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

创建一个客户端证书的方法为:

openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"

静态Token文件

使用静态Token文件认证只需要API Server启动时配置--token-auth-file=SOMEFILE。该文件为csv格式,每行至少包括三列token,username,user id,后面是可选的group名,比如

token,user,uid,"group1,group2,group3"

客户端在使用token认证时,需要在请求头中加入Bearer Authrization头,比如

Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

引导Token

引导Token是动态生成的,存储在kube-system namespace的Secret中,用来部署新的Kubernetes集群。

使用引导Token需要API Server启动时配置--experimental-bootstrap-token-auth,并且Controller Manager开启TokenCleaner --controllers=*,tokencleaner,bootstrapsigner

在使用kubeadm部署Kubernetes时,kubeadm会自动创建默认token,可通过kubeadm token list命令查询。

静态密码文件

需要API Server启动时配置--basic-auth-file=SOMEFILE,文件格式为csv,每行至少三列password, user, uid,后面是可选的group名,如

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

客户端在使用密码认证时,需要在请求头重加入Basic Autorization头,如

Basic BASE64ENCODED(USER:PASSWORD)

Service Account

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

在认证时,ServiceAccount的用户名格式为system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT),并从属于两个group:system:serviceaccountssystem:serviceaccounts:(NAMESPACE)

OpenID

OpenID提供了OAuth2的认证机制,是很多云服务商(如GCE、Azure等)的首选认证方法。

使用OpenID认证,API Server需要配置

  • --oidc-issuer-url,如https://accounts.google.com
  • --oidc-client-id,如kubernetes
  • --oidc-username-claim,如sub
  • --oidc-groups-claim,如groups
  • --oidc-ca-file,如/etc/kubernetes/ssl/kc-ca.pem

Webhook

API Server需要配置

# 配置如何访问webhook server
--authentication-token-webhook-config-file
# 默认2分钟
--authentication-token-webhook-cache-ttl

配置文件格式为

# 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

Kubernetes发给webhook server的请求格式为

{
  "apiVersion": "authentication.k8s.io/v1beta1",
  "kind": "TokenReview",
  "spec": {
    "token": "(BEARERTOKEN)"
  }
}

示例:kubernetes-github-authn实现了一个基于WebHook的github认证。

认证代理

API Server需要配置

--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-
# 为了防止头部欺骗,证书是必选项
--requestheader-client-ca-file
# 设置允许的CN列表。可选。
--requestheader-allowed-names

OpenStack Keystone密码

需要API Server在启动时指定--experimental-keystone-url=<AuthURL>,而https时还需要设置--experimental-keystone-ca-file=SOMEFILE

[warning] 不支持Keystone v3

目前只支持keystone v2.0,不支持v3(无法传入domain)。

匿名请求

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

匿名请求的用户名格式为system:anonymous,而group则为system:unauthenticated

授权

认证之后的请求就到了授权模块。跟认证类似,Kubernetes也支持多种授权机制,并支持同时开启多个授权插件(只要有一个验证通过即可)。如果授权成功,则用户的请求会发送到准入控制模块做进一步的请求验证;而对于授权失败的请求则返回HTTP 403.

Kubernetes授权仅处理以下的请求属性:

  • user, group, extra
  • API、请求方法(如get、post、update、patch和delete)和请求路径(如/api
  • 请求资源和子资源
  • Namespace
  • API Group

目前,Kubernetes支持以下授权插件:

  • ABAC
  • RBAC
  • Webhook

[info] AlwaysDeny和AlwaysAllow

Kubernetes还支持AlwaysDeny和AlwaysAllow模式,其中AlwaysDeny仅用来测试,而AlwaysAllow则 允许所有请求(会覆盖其他模式)。

ABAC授权

使用ABAC授权需要API Server配置--authorization-policy-file=SOME_FILENAME,文件格式为每行一个json对象,比如

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group":"system:authenticated",  "nonResourcePath": "*", "readonly": true}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group":"system:unauthenticated", "nonResourcePath": "*", "readonly": true}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"admin",     "namespace": "*",              "resource": "*",         "apiGroup": "*"                   }}

RBAC授权

RBAC授权

WebHook授权

使用WebHook授权需要API Server配置--authorization-webhook-config-file=SOME_FILENAME--runtime-config=authorization.k8s.io/v1beta1=true,配置文件格式同kubeconfig,如

# clusters refers to the remote service.
clusters:
  - name: name-of-remote-authz-service
    cluster:
      certificate-authority: /path/to/ca.pem      # CA for verifying the remote service.
      server: https://authz.example.com/authorize # 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-authz-service
    user: name-of-api-server
  name: webhook

API Server请求Webhook server的格式为

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "kittensandponies",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    },
    "user": "jane",
    "group": [
      "group1",
      "group2"
    ]
  }
}

而Webhook server需要返回授权的结果,允许(allowed=true)或拒绝(allowed=false):

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "status": {
    "allowed": true
  }
}

results matching ""

    No results matching ""