kubernetes集群系列资料15--安全机制介绍

一、K8S集群安全介绍

　　安全机制说明：API server是K8S集群内部各个组件通信的中介，也是外部控制的入口，因此K8S安全机制基本围绕API server来设计的。K8S采用认证(authentication)、鉴权(authorization)、准入控制(admission control)三步来保证API server的安全。

 认证(authentication)

　　1）http token认证：用一个token（很长的特殊编码方式的且难以被模仿的字符串）来表达客户的一种方式。每一个token对应一个用户名，并被存储在API server能访问的文件中。当客户端发起API调用请求时，需要在http header里放入token。由于token存放在文件中，未存放在ETCD中，其安全性较低。
　　2）http base认证：通过“用户名+密码”的方式认证，“用户名+密码”采用base64算法进行编码后，其字符串被放在http request中的heather Authentication域里发送给服务端，服务端收到后进行解码，获取“用户名+密码”。这种方法的数据流被截取后，“用户名+密码”容易被解密。
　　3）http证书认证：基于CA根证书签名的客户端身份认证方式。前2种方法，仅是针对客户端进行认证，不能对服务端进行认证，且使用安全性低。在K8S域中，会签发一个根证书，然后客户端及服务端申请下方CA证书，采用随机私钥加密后传输，于是二者互相进行双向认证，采用随机私钥加密后传输数据。

需要认证的场景及对象：

　　a、K8S各组件对API server的访问，如：controller Manager、scheduler与API server在同一台机器，所以直接使用API server的非安全端口访问，--insecure-bind-address=127.0.0.1；kubectl、kubelet、kube-proxy访问API server就都需要证书进行https双向认证。
　　b、K8S管理的pod对API server的访问，如：pod（dashboard也是以pod形式运行）；
证书颁发非常消耗资源（生产环境使用SA替代），其方式有：
　　a、手动签发：通过K8S集群的根CA进行签发https证书。
　　b、自动签发：kubelet首次访问API server时，使用token做认证，通过后,controller manager会为kubelet生成一个证书，以后的访问都是用证书做认证了。

kubeconfig：文件包含集群参数（CA证书、API server地址），客户端参数（上面生成的证书和私钥），集群context信息（集群名称、用户名）。k8s组件通过启动时指定不同的kubeconfig文件可以切换到不同的集群；比如：/root/.kube/config；

serviceAccount：pod中容器访问API server。因为pod的创建、销毁是动态的，所以要为它手动生成证书就不可行了。K8S使用了SA解决pod访问API server的认证问题。

secret与SA的关系：K8S设计了一种资源对象叫做secret，分为2类，一种是用于serviceAccount的service-account-token，另一种是用于保存用户自定义保密信息的opaque。serviceAccount中用到包含3个部分：token、ca.crt、namespace。
　　token：是使用API server私钥签名的JWT。用于访问API server时，server端认证。
　　ca.crt:根证书。用于client端验证API server发送的证书。
　　namespace:表示这个service-account-tonken的作用域空间。
kubectl get secret --all-namespaces #查看所有secret；
kubectl describe secret default-token-f2d2q -n kube-system #查看default-token-f2d2q文件；
　　JWT(json web token)，是为了在网络应用环境中传递声明而执行的一种基于JSON的开放标准，该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录SSO场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其他业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。
默认情况下，每个namespace都会有一个serviceAccount，如果pod在创建时没有指定serviceAccount，就会使用pod所属的namespace的serviceAccount。 pod默认挂载目录为/run/secrets/kubernetes.io/serviceaccount/；

pod访问API server：pod首先访问SA，然后通过service-account-token访问API server。

kubectlkube-proxy需要手动签发证书，然后通过kubeconfig访问API server。

kubelet经过TLS安全加密后获取证书，通过kubeconfig访问API server。

二、鉴权(authorization)

鉴权(authorization)：确定请求方获取资源的权限。目前API server支持以下授权策略（通过API server的启动参数"--authorization-mode设置"）：
　　1）AlwaysDeny：表示拒绝所有的请求，一般用于测试；
　　2）AlwaysAllow：允许接受所有请求，如果集群不需要授权流程，则可用该策略。
　　3）ABAC(Attribute-Based Access Control)：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制；K8S老版本才会有，需要定义很多属性，比较复杂。
　　4）Webbook：通过调用外部REST服务对用户进行授权。即只能在K8S集群外进行鉴权。
　　5）RBAC(Role-Based Access Control)：基于角色的访问控制，目前的默认规则。
RBAC授权模式：在K8S 1.5中引入，相比其他方式有如下优势：
　　1）对集群中的资源(pod、deployment、cpu...)和非资源(metadata...)均拥有完整的覆盖；
　　2）整个RBAC完全由几个API对象完成，可用kubectl或API进行操作；
　　3）可以在运行时进行调整，无需重启API Server；

RBAC的API资源对象说明
　　RBAC引入了4个新的顶级资源对象：role、clusterRole、roleBinding、clusterRoleBinding，4种对象类型均可以通过kubectl与API操作。

 RBAC的API资源对象说明

　　RBAC引入了4个新的顶级资源对象：role、clusterRole、roleBinding、clusterRoleBinding，4种对象类型均可以通过kubectl与API操作。
　　注意：K8S并不会提供用户管理，那么user、group、serviceAccount指定的用户又是从哪里来的呢？K8S组件或是其他自定义的用户在向CA申请证书时，需要提供要给证书请求文件。
　　API server会把客户端证书的CN字段作为User，把names.O字段作为Group；kubelet使用TLS Bootstraping认证时，API server可以使用Bootstrap Tokens或Token authentication file验证=token，无论哪一种K8S都会为token绑定一个默认的User和group；pod使用SA认证时，service-account-token种的JWT会保存user信息，有了用户信息，在创建一对role/clusterRole（roleBinding/clusterRoleBinding）资源对象，就可以完成权限绑定了。

          {
            "CN": "admin",
            "hosts": [],
            "key": {
              "algo": "rsa",
              "size": 2048
            },
            "name": [
              {
                "C": "CN",
                "ST": "HangZhou",
                "L": "XS",
                "O": "system:masters",
                "OU": "System"
              }
            ]
          }

Role and ClusterRole
　　在RBAC API中，role表示一组规则权限，权限只会增加（累加权限），不存在一个资源一开始就有很多权限而通过RBAC对其进行减少的操作；role可以定义在一个namespace中，如果想要跨namespace则可以创建clusterRole。

        kind: Role
        apiVersion: rbac.authorization.k8s.io/v1beta1
        metadata:
          namespace: default
          name: pod-reader
        rules:
        - apiGroups: [""] # ""indicates the core API group;
          resources: ["pods"]
          verbs: ["get","watch","list"]   #该组具有的权限；

clusterRole具有与role相同的权限角色控制能力，不同的是clusterRole是集群级别的，clusterRole可用于：集群级别的资源控制（如：node访问权限），非资源型endpoints（如：/healthz），所命名空间资源控制（如：pods）；　　

        kind: ClusterRole
        apiVersion: rbac.authorization.k8s.io/v1beta1
        metadata:
          # “namespace” ommited since ClusterRoles are not namespaced.
          name: secret-reader
        rules:
        - apiGroups: [""]                 # ""indicates the core API group;
          resources: ["secrets"]
          verbs: ["get","watch","list"]   #该组具有的权限；

RoleBinding and ClusterRoleBinding
　　RoleBinding可以将角色中定义的权限授予用户或用户组，RoleBinding包含一组权限列表subjects，权限列表中包含有不同形式的待授予权限资源类型（users、groups、service accounts）；RoleBinding同样包含对被bind的role引用；RoleBinding适用于某个命名空间内授权，而ClusterRoleBinding适用于集群范围内的授权。

        ####将default命名空间的pod-reader role授予jane用户，此后jane用户在default命名空间中将具有pod-reader的权限。
        kind: RoleBinding
        apiVersion: rbac.authorization.k8s.io/v1beta1
        metadata:
          name: read-pods
          namespace: default
        subjects:
        - kind: User
          name: jane
          apiGroup: rbac.authorization.k8s.io
        roleRef:
          kind: Role
          name: pod-reader
          apiGroup: rbac.authorization.k8s.io

RoleBinding同样可引用一个ClusterRole对当前namespace内user、group、SA进行授权，这种操作允许集群管理员在整个集群内定义一些通用的ClusterRole，然后在不同的namespace中使用RoleBinding来引用。
　　例如：以下RoleBinding引用了一个ClusterRole，这个ClusterRole具有整个集群内对secrets的访问权限；但是其授权用户dave只能访问development空间中的secrets（因为RoleBinding定义在development名称空间）

      # this role binding allows "dave" to read secrets in the "development" namespace.
        kind: RoleBinding
        apiVersion: rbac.authorization.k8s.io/v1beta1
        metadata:
          name: read-secrets
          namespace: deployment
        subjects:
        - kind: User
          name: dave
          apiGroup: rbac.authorization.k8s.io
        roleRef:
          kind: ClusterRole
          name: secret-reader
          apiGroup: rbac.authorization.k8s.io

 使用ClusterRoleBinding可对整个集群中所有命名空间资源权限进行授权；以下ClusterRoleBinding样例展示了授权manager组内所有用户在全部命名空间中对secrets进行访问。　　

      # this cluster role binding allows anynoe in the "manager" group to read secrets in any namespace.
        kind: ClusterRoleBinding
        apiVersion: rbac.authorization.k8s.io/v1beta1
        metadata:
          name: read-secrets-global
        subjects:
        - kind: Group
          name: manager
          apiGroup: rbac.authorization.k8s.io
        roleRef:
          kind: ClusterRole
          name: secret-reader
          apiGroup: rbac.authorization.k8s.io        

resources
　　K8S集群内一些资源一般会议其名称字符串来表示，这些字符串一般会在API的URL地址中出现；同时某些资源也会包含子资源，如logs资源就属于pods的子资源，API中URL样例如下：
　　　　GET /api/v1/namespaces/{namespace name}/pods/{pod name}/log
　　如果要在RBAC授权模型中控制这些子资源的访问权限，可以通过/分隔符来实现；
　　以下是一个定义pods资源logs访问权限的role定义样例：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]       
  resources: ["pods/log"]
  verbs: ["get","list"] 

subjects
　　RoleBinding和ClusterRoleBinding可以将Role绑定到subjects；subjects可以是groups、users、SA；subjects中users使用字符串表示，它可以是一个普通的名字字符串，如“alice”，也可以是email格式，如“wang@qq.com";亦可以是一组字符串形式的数字ID。但是users的前缀system:是系统保留的，集群管理员应该确保普通用户不会使用这个前缀格式。groups书写格式于users相同，都为一个字符串，并没有特定的格式要求，前缀system:是系统保留的。

案例1：创建一个用户只能管理dev空间　

##k8s集群没有用户管理的组件，因此需要在master上创建用户;
useradd devuser
echo password |passwd devuser --stdin
grep devuser /etc/passwd
##测试新用户是否能使用K8S集群；
su devuser
kubectl get pod  #返回错误；需要创建证书，用户才可使用K8S集群；

##创建证书请求json文件；CN字段为用户名，O字段为组名，algo为算法名称，size指算法的长度；
cat >devuser-cert.json<<eof
{
  "CN": "devuser",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "name": [
    {
      "C": "CN",
      "ST": "BeiJing",
      "L": "BeiJing",
      "O": "k8s",
      "OU": "System"
    }
  ]
}
eof
##下载证书生成工具
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
mv cfssl_linux-amd64 /usr/local/bin/cfssl
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo
chmod a+x /usr/local/bin/cfssl*
cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes devuser-cert.json |cfssljson -bare devuser #生成devuser证书；-ca指定ca证书，-ca-key指定私钥，devuser-cert.json为创建证书的请求文件，cfssljson -bare devuser指定输出文件的格式；

 devuser.csr为请求证书请求，devuser-key.pem为私钥，devuser.pem为证书。

##设置K8S集群参数
export KUBE_APISERVER="https://192.168.66.10:6443"
kubectl config set-cluster kubernetes 
    --certificate-authority=/etc/kubernetes/pki/ca.crt 
    --embed-certs=true 
    --server=${KUBE_APISERVER} 
    --kubeconfig=devuser.kubeconfig

 此时配置中很多为空。

##设置客户端认证参数
kubectl config set-credentials devuser 
    --client-certificate=/etc/kubernetes/pki/devuser.pem 
    --client-key=/etc/kubernetes/pki/devuser-key.pem 
    --embed-certs=true 
    --kubeconfig=devuser.kubeconfig

##设置上下文参数
kubectl config set-context kubernetes 
    --cluster=kubernetes 
    --user=devuser 
    --namespace=dev 
    --kubeconfig=devuser.kubeconfig

##设置默认上下文
su - devuser -c "mkdir /home/devuser/.kube"
cp -f devuser.kubeconfig /home/devuser/.kube
chown devuser:devuser /home/devuser/.kube/devuser.kubeconfig
mv /home/devuser/.kube/devuser.kubeconfig /home/devuser/.kube/config
su - devuser -c "ls -l /home/devuser/.kube"
kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev #创建一个rolebindding，使得devuser可在dev名称空间具有完全控制权（admin权限）；
su - devuser
cd /home/devuser/.kube;kubectl config use-context kubernetes --kubeconfig=config  #切换devuser账户进行设置默认上下文，此后devuser即可访问K8S集群。

此时，默认devuser进入dev名称空间，并对其中的资源进行管理。 于是对不同用户的鉴权即可通过证书完成。

　

准入控制(admission controller)
　　准入控制是API server的插件集合，通过添加不同的插件，实现额外的额准入控制规则。甚至于API SERVER的一些主要的功能都需要通过admission controller实现，比如SA;
　　不同K8S版本的准入控制器是不一样的，需要查阅官方文档，准入控制通过不同的插件实现不同的功能更。
K8S1.14版本准入控制器插件推荐列表如下：
　　NamespaceLifecyle:防止不存在的namespace上创建对象，防止删除系统预置namespace，删除namespace时，连带删 除它的所有资源对象。
　　LimitRanger：确保请求的资源不会超过资源所在Namespace的LimitRange的限制。
　　ServiceAccount：实现了自动化添加ServiceAccount；
　　ResourceQuota：确保请求的资源不会超过资源的ResourceQuota限制。
　　****一般准入控制使用默认的规则中。
现行安全机制为：https双向认证、RBAC鉴权、默认准入控制（可添加额外插件）。