这些 kubernetes 的安全机制你都了解吗？

我们都知道 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))
}
如果我们想实现自己的准入控制插件，只要实现这个接口即可，使用起来非常简单。
 
参考文献
 
https://www.cyberciti.biz/faq/authentication-vs-authorization/
https://kubernetes.io/docs/admin/accessing-the-api/
https://kubernetes.io/docs/admin/authorization/
https://kubernetes.io/docs/admin/admission-controllers/
kubernetes权威指南