集群安全机制

1、概述
  • 访问k8s集群时，需要经过三个步骤，才能完成具体操作
    • 第一步 认证
      • 身份验证（如日常使用，用户）
    • 第二步 鉴权（授权）
      • 身份权限（如日常使用，角色）
    • 第三步 准入控制
      • 行为控制（如日常使用，ACL访问控制列表）
2、进行访问时，过程中需要经过apiserver，apierver做统一协调，如门卫。访问过程中需要证书、token、或者用户名+密码，如果访问pod需要serviceAccount
notion image
  • 第一步认证 传输安全
    • 传输安全：对外不暴露8080端口，仅能内部访问，对外使用6443端口
    • 认证
      • 客户端身份常用方式
        • https证书认证，基于ca证书（推荐，目前此种方式最安全，如：部署二进制安装包生成证书文件）
        • http token认证，通过token识别用户（如：使用yum安装，时添加node节点时操作）
        • http基本认证，用户名+密码认证（此种方法不安全，不推荐）
  • 第二步鉴权（授权）
    • 基于RBAC进行鉴权操作
    • 基于角色访问控制
  • 第三步 准入控制
    • 准入控制器列表，如果列表有请求内容则通过，反之拒绝
3、RBAC 基于角色访问控制（Role-based-Access-Control）
Kubernetes权限管理之RBAC （一）
k8s在启用基于角色管理的访问控制 RBAC（Role-based-Access-Control）的授权模式。相当于基于属性的访问控制ABAC（Attribute-based Access Control）,RBAC主要是引入了 角色（Role 权限的集合） 和角色绑定（RoleBinding）的抽象概念。在ABAC中，k8s集群中的访问策略只能跟用户直接关联；而RBAC中，访问策略可以跟某个角色关联，具体的用户再和某个角色或者多个角色关联。 RBAC有四个新的k8s顶级资源对象： 角色（Role）、集群角色（ClusterRole）、角色绑定（RoleBinding）、集群角色绑定（ClusterRoleBinding）。同其他API资源对象一样，用户可以使用kubectl或者API调用方式等操作这些资源对象。 RBAC具有如下优势。 1、对集群中的资源和非资源权限均有完整的覆盖。 2、整个RBAC完全由几个API对象完成，同其他API对象一样 ，可以用kubectl或API进行操作。 3、可以在运行时进行调整，无须重新启动 API Server。 4、要使用 RBAC 授权模式 ，则 需要在 API Server 的启动 参数中 加上--authorization-mode=RBAC。 1）角色( Role) 一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。在一个命名空间中，可以用角色来定义一个角色，如果是集群级别的，就需要使用ClusterRole了。角色只能对命名空间内的资源进行授权，下面例子中定义的角色具备读取Pod的权限: kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: default //这里指的是default命名空间下的角色 name: pod-reader rules: - apiGroups: [""] # ""空字符串，表示核心API群 resources: ["pods"] //要操作的资源 verbs: ["get",
Kubernetes权限管理之RBAC （一）
https://zhuanlan.zhihu.com/p/281294170
Kubernetes权限管理之RBAC （一）
定义一个角色A（角色命名）
对角色A定义一组权限（相当于规划做一此权限控制）
角色A对用户A进行角色绑定（用户加入某个角色）
notion image
  • 角色
    • role：特定命名空间
    • ClusterRole：所有命令空间访问
  • 角色绑定
    • roleBinding：角色绑定至主体
    • ClusterRoleBingding：集群角色绑定到主体
  • 主体
    • user：用户
    • group：用户组
    • serviceAccout：服务账号
      •  
示例
  • 创建命名空间
  • 在新创建的命名空间创建Pod
  • 创建角色
  • 创建角色绑定用户
  • 使用证书识别身份
 
Loading...
目录