Kubernetes API 访问控制

可以使用kubectl客户端库方式对REST API的访问,Kubernetes的普通账户和Service帐户都可以实现授权访问API。API的请求会经过多个阶段的访问控制才会被接受处理,其中包含认证、授权以及准入控制(Admission Control)等。如下图所示:

Kubernetes API请求的请求处理步骤图

需要注意:认证授权过程只存在HTTPS形式的API中。也就是说,如果客户端使用HTTP连接到kube-apiserver,是不会进行认证授权的。所以说,可以这么设置,在集群内部组件间通信使用HTTP,集群外部就使用HTTPS,这样既增加了安全性,也不至于太复杂。

认证

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

当TLS建立时,HTTP请求会进行身份认证步骤,如图中步骤1,集群管理器将apiserver配置为运行一个或多个认证器模块。

认证模块包含客户端证书,密码、Plain Tokens、Bootstrap Tokens、JWT Tokens(used for service accounts)。

我们可以指定多个认证模块,每个认证模块都会按顺序进行,直到其中一个成功。

(在GCE上,客户端证书、密码、Plain Tokens和JWT Tokens都会启用。)

更多认证模块的使用方法可以参考 认证

授权

认证之后的请求是授权模块。如图中步骤2  。

请求必须包含请求者的用户名,请求的操作以及受该操作影响的对象,如果策略已经声明用户具有完成请求的权限,则该请求将被授权。

例如:设置如下Bob策略,那么会在namespace projectCaribou 中读取pods

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "bob",
        "namespace": "projectCaribou",
        "resource": "pods",
        "readonly": true
    }
}

如果Bob发出以下请求,被允许读取projectCaribou namespace中的对象,请求被授权

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "projectCaribou",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    }
  }
}
  • 如果Bob向projectCaribou namespace中对象写入(create或update)请求,则会拒绝其授权。
  • 如果Bob请求在不同的namespace中读取(get)对象,比如projectFish,授权也将被拒绝。

Kubernetes授权要求使用公共常见得REST属性与云提供商的访问控制系统进行交互。为了避免访问控制系统与Kubernetes API与外部API的冲突,所以必须使用REST格式。

Kubernetes支持多种授权模块,如ABAC模式RBAC模式和Webhook模式。当管理员创建集群时,他们将会配置在API Server中使用的授权模块。如果配置了多个授权模块,Kubernetes会检查每个模块,当通过其中任何模块授权请求,则授权成功,如果所有模块都拒绝了该请求,则授权失败(HTTP 403)。

了解Kubernetes授权的更多信息,参靠授权概述

准入控制(Admission Control)

准入控制(Admission Control)用来对请求做进一步的验证或添加默认参数,除了授权模块可用的属性外,准入控制模块还可以访问正在创建或更新对象内容。

也可以可以配置多个准入控制器,每个都会按顺序调用。

如图中步骤3。

Kubernetes API请求的请求处理步骤图

与认证和授权模块不同,任何接入控制器模块被遭拒时,请求会立即失败。

当请求通过了所有准入控制(Admission Control),就会使用相应API对象的验证功能,然后写入对象存储(如步骤4所示)

API Server端口和IPs

之前讨论用于发送到API Server安全端口的请求(经典情况)。API Server实际上可以在两个端口上服务:

默认情况下,Kubernetes API Server在2个端口上提供HTTP:

  1. Localhost Port:
     - is intended for testing and bootstrap, and for other components of the master node
       (scheduler, controller-manager) to talk to the API
     - no TLS
     - default is port 8080, change with `--insecure-port` flag.
     - defaults IP is localhost, change with `--insecure-bind-address` flag.
     - request **bypasses** authentication and authorization modules.
     - request handled by admission control module(s).
     - protected by need to have host access
    
  2. Secure Port:
     - use whenever possible
     - uses TLS.  Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag.
     - default is port 6443, change with `--secure-port` flag.
     - default IP is first non-localhost network interface, change with `--bind-address` flag.
     - request handled by authentication and authorization modules.
     - request handled by admission control module(s).
     - authentication and authorisation modules run.

在Google Compute Engine(GCE)或其他云提供商使用kube-up.sh创建集群时

  • API Server提供 443端口
  • GCE项目配置防火墙
  • 允许API进行外部HTTPS访问