k8s安全认证

▶ 访问控制概述

k8s所谓的安全性其实就是保证对k8s的各种客户端进行认证和鉴权操作。

认证：身份鉴别，只有正确的账号才能够通过认证

授权：判断用户是否由权限对访问的资源执行特定的动作

准入控制：用于补充授权机制以实现更加精细的访问控制能力

▶ 认证管理

• HTTP Base认证

通过用户名+密码的方式认证，用base64算法进行加密。

• HTTP Token

通过一个Token来识别合法用户，这种认证方式是用一个很长的难以被模仿的字符串--Token来表名 客户身份的一种方式。

• HTTPS证书认证

基于CA根证书签名的双向数字证书认证方式。这种认证方式是安全性最高的一种方式，但是同时也是操作起来最麻烦的一种方式。

▶ 授权管理

授权发生在认证成功之后，通过认证就可以知道请求用户是谁，然后k8s会根据事先定义的授权策略来决定用户是否由权限访问，这个过程就称为授权。

• API Server目前支持以下几种授权策略：

AlwaysDeny：表示拒绝所有请求，一般用于测试

AlwaysAllow：允许接收所有请求，相当于集群不需要授权流程（默认）

RBAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制

Webhook：通过调用外部REST服务对用户进行授权（）

REST，即表述性状态传递，是一种软件架构风格，用于涉及和开发网络应用程序。

▶ Role、ClusterRole

一个角色就是一组权限的集合。

yaml文件：

apiVersion: rbac.authorization.k8s.ip/v1
kind: Role/ClusterRole
metadata:
name: authorization-role
namespace: demo #clusterRole没有命名空间，是全局性资源
rules:
- apiGroups: [""] #支持的API组列表，""表示核心API群
relources: ["pods"] #支持的资源对象列表
verbs: ["get","watch","list"] #允许的操作方法
### ▶ RoleBinding、ClusterRoleBinding

角色绑定用来把一个角色绑定到一个目标对象上，绑定目标可以是User、Group或者是ServiceAccount。

yaml文件：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding/ClusterRoleBinding
metadata:
name: xxx
namespace: demo #clusterRoleBinding没有命名空间
subjects:
- kind: User
name: wz
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: authorization-role
apiGroup: rbac.authorization.k8s.io
### ▶ 创建一个账号
####  1.创建证书
cd /etc/kubernetes/pki/
(umask 066;openssl genrsa -out devman.key 2048)
####  2.用apiserver的证书去签署

▪ 签名申请，申请的用户是devman，组是devgroup

openssl req -new -key devman.key -out devman.csr -subj "/CN=devman/O=devgroup"

生成了一个证书签名请求（CSR）

poenssl req：OpenSSL工具的命令行接口，用于执行各种加密

-new：创建一个新的CSR

-key devman.key：使用此私钥文件

-out devman.csr：指定输出CSR文件名称

-subj "/CN=devman/O=devgroup"：指定CSR的主题信息

▪ 生成一个自签名的x.509证书

openssl x509 -req -in devman.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out devman.crt -days 3650

openssl x509：OpenSSL工具的命令行接口，用于执行各种加密

-req：要创建一个新的x.509证书请求

-in devman.csr：指定使用CSR文件

-CA ca.crt -CAkey ca.key：指定使用CA的证书和私钥文件

-CAcreateserial：创建证书时自动生成一个序列号

-out devman.crt：指定输出crt证书文件名称

-days 3650：证书有效天数

3.设置集群、用户、上下文信息

kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://172.23.4.48:6443

在k8s集群中设置用户凭证，该操作如果API地址已经存在，可以不做该步

**坑点：https://xxx.xxx.xxx.x:6443不可写错！！写错集群不可用**

kubectl config set-credentials devman --embed-certs=true --client-certificate=/etc/kubernetes/pki/devman.crt --client-key=/etc/kubernetes/pki/devman.key
kubectl config set-context devman@kubernetes --cluster=kubernetes --user=devman

设置上下文

4.切换用户到devman

kubectl config use-context devman@kubernetes

(此时该用户没有权限）

▶ 授权用户devman

创建Role和RoleBinding：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: demo-role
namespace: demo
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get","watch","list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: demo-rolebinding
namespace: demo
subjects:
- kind: User
name: devman
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: demo-role
apiGroup: rbac.authorization.k8s.io