Kubernetes 的安全机制 APIServer 认证、授权、准入控制

本文讲解 kubernetes 的安全机制。主要会按照这几个部分来讲解：APIServer 认证、授权、准入控制等。

我们都知道 kubenetes 默认在两个端口提供服务：一个是基于 https 安全端口 6443，另一个是基于 http 的非安全端口 8080。其中非安全端口 8080 限制只能本机访问，即绑定的是 localhost。

对于安全端口来讲，一个 API 请求到达 6443 端口后，主要经过以下几步处理：

认证
授权
准入控制
实际的 API 请求

APIServer 认证

Authentication verifies who you are.

认证的接口为：

// Request attempts to extract authentication information from a request and returns // information about the current user and true if successful, false if not successful, // or an error if the request could not be checked.
 type Request interface { AuthenticateRequest(req *http.Request) (user.Info, bool, error) } // Info describes a user that has been authenticated to the system.
 type Info interface { GetName() string GetUID() string GetGroups() []string GetExtra() map[string][]string } 也就是说，认证的目的是识别出访问者是谁，识别出访问者身份之后，具体有没有权限执行某个操作则是由“ 授权模块 ”来完成。

kubernetes 认证主要分为三种：CA 证书认证、Token 认证、Base 认证。可以同时配置多种认证方式，只要其中任意一个方式认证通过即可。

APIServer 授权

Authorization verifies what you are authorized to do.

授权就是授予不同用户不同的访问权限，APIServer 目前支持以下几种授权策略：

AlwaysDeny：表示拒绝所有的请求，该配置一般用于测试
AlwaysAllow：表示接收所有请求，如果集群不需要授权，则可以采取这个策略
ABAC：基于属性的访问控制，表示基于配置的授权规则去匹配用户请求，判断是否有权限。Beta 版本
RBAC：基于角色的访问控制，允许管理员通过 api 动态配置授权策略。Beta 版本

RBAC 主要还是基于私有云的那种授权思路，网易云基础服务（蜂巢）是基于 ABAC 自己开发的一套用户隔离的授权策略。因此接下来主要讲解一下 ABAC。

授权的接口为：

type Authorizer interface { Authorize(a Attributes) (err error) } // Attributes is an interface used by an Authorizer to get information about a request // that is used to make an authorization decision.
 type Attributes interface { GetUserName() string GetGroups() []string GetVerb() string IsReadOnly() bool // The namespace of the object, if a request is for a REST object. GetNamespace() string // The kind of object, if a request is for a REST object. GetResource() string // GetSubresource returns the subresource being requested, if present GetSubresource() string GetName() string GetTenantId(tenantId string) }

其实主要有六个基本属性：

用户名，代表一个已经被认证的用户的 id
是否是只读请求
请求类型，比如 GET、List、Watch 等
资源类型，比如 pods、nodes 等
namespace，被访问对象所属的 namespace
tenantid，被访问对象所属的租户 id

假如用户 A 发来请求 /api/v1/namespaces/nsa/pods/pda，那么我们可以通过这个请求以及 apiserver 的缓存，设置好上面的五个基本属性，为接下来的授权做好准备工作：

用户名：A
只读：是
请求类型：GET
namespace：nsa
资源类型：pods
tenantid：一个租户下面可以由多个 namespace，namespace 的 label 中设置了它属于哪个租户

接下来，看一下如何配置授权策略。

比如，我们限制集群内的用户只能访问自己租户的 persistentvolumes 资源，并且只能执行 get、list 和 watch 请求，那么对应的授权规则为：

{"ruleName": "kubelet", "resource": "persistentvolumes", "tenantId": "self", "method": "get&list&watch"}

限制集群内的用户能访问集群内的所有 pods 资源，但是只有对自己租户的 pods 资源才具有更改权限，那么对应的授权策略为：

{"ruleName": "kubelet", "resource": "pods", "tenantId": "self","method":"*"} {"ruleName": "kubelet", "resource": "pods", "tenantId":"*","method": "get&list&watch"}

其中“ * ”表示匹配所有。
我们可以定义多条授权策略，只要有一条通过即授权通过。

Admission Control 准入控制

通过了前面的认证和授权之后，还需要经过准入控制处理通过之后，apiserver 才会处理这个请求。Admission Control 有一个准入控制列表，我们可以通过命令行设置选择执行哪几个准入控制器。只有所有的准入控制器都检查通过之后，apiserver 才执行该请求，否则返回拒绝。

当前可配置的准入控制器主要有：

AlwaysAdmit：允许所有请求
AlwaysDeny：拒绝所有请求
AlwaysPullImages：在启动容器之前总是去下载镜像
ServiceAccount：将 secret 信息挂载到 pod 中，比如 service account token，registry key 等
ResourceQuota 和 LimitRanger：实现配额控制
SecurityContextDeny：禁止创建设置了 Security Context 的 pod

准入控制的接口定义为：

// Interface is an abstract, pluggable interface for Admission Control decisions.
 type Interface interface { // Admit makes an admission decision based on the request attributes Admit(a Attributes) (err error) // Handles returns true if this admission controller can handle the given operation // where operation can be one of CREATE, UPDATE, DELETE, or CONNECT Handles(operation Operation) bool }

type Handler struct {
 operations sets.String } // Handles returns true for methods that this handler supports
 func (h *Handler) Handles(operation Operation) bool { return h.operations.Has(string(operation)) }

如果我们想实现自己的准入控制插件，只要实现这个接口即可，使用起来非常简单。

本文转自中文社区-Kubernetes 的安全机制 APIServer 认证、授权、准入控制

Kubernetes 的安全机制 APIServer 认证、授权、准入控制

APIServer 认证

APIServer 授权

Admission Control 准入控制

你可能感兴趣的:(Kubernetes 的安全机制 APIServer 认证、授权、准入控制)