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访问