- 最新动态
- 功能总览
- 产品介绍
- 计费说明
- 快速入门
- 用户指南
- 最佳实践
- 开发指南
-
API参考
- 使用前必读
- 如何调用API
- 快速入门
- API
-
Kubernetes API
- ConfigMap
- Pod
- StorageClass
- Service
- Deployment
- Ingress
- OpenAPIv2
- VolcanoJob
- Namespace
- ClusterRole
- Secret
- Endpoint
- ResourceQuota
- CronJob
-
API groups
- 查询APIVersions
- 查询所有v1版本的API
- 查询APIGroupList
- 查询APIGroup /apis/apps
- 查询所有apps/v1的API
- 查询APIGroup /apis/batch
- 查询APIGroup /apis/batch.volcano.sh
- 查询所有batch.volcano.sh/v1alpha1的API
- 查询所有batch/v1的API
- 查询所有batch/v1beta1的API
- 查询APIGroup /apis/crd.yangtse.cni
- 查询所有crd.yangtse.cni/v1的API
- 查询APIGroup /apis/extensions
- 查询所有extensions/v1beta1的API
- 查询APIGroup /apis/metrics.k8s.io
- 查询所有metrics.k8s.io/v1beta1的API
- 查询APIGroup /apis/networking.cci.io
- 查询所有networking.cci.io/v1beta1的API
- 查询APIGroup /apis/rbac.authorization.k8s.io
- 查询所有rbac.authorization.k8s.io/v1的API
- Event
- PersistentVolumeClaim
- RoleBinding
- StatefulSet
- Job
- ReplicaSet
- 数据结构
- 权限和授权项
- 附录
- 历史API
- 修订记录
- SDK参考
- 场景代码示例
- 常见问题
- 视频帮助
- 文档下载
- 通用参考
展开导读
链接复制成功!
身份认证与访问控制
CCI当前认证鉴权是在Kubernetes的角色访问控制(RBAC)与统一身份认证服务(IAM)的能力基础上,提供的基于IAM的细粒度权限控制和IAM Token认证,同时支持命名空间级别及命名空间以下资源的权限控制,帮助用户便捷灵活的对租户下的IAM用户、用户组设定不同的操作权限。
- 命名空间权限:是基于Kubernetes RBAC能力的授权。通过权限设置可以让不同的用户或用户组拥有操作指定Namespace下Kubernetes资源的权限。
- CCI权限:是基于IAM的细粒度授权。通过命名空间级别权限设置可以控制用户操作Namespace(如创建、删除Namespace等)。更多细粒度权限说明请参见CCI细粒度鉴权系统策略关联Actions。
- CCI服务暂不支持Landingzone场景。
- 创建Namespace时,打开RBAC鉴权开关,则此Namespace下资源访问受RBAC鉴权控制;如果未打开RBAC鉴权开关,则RBAC鉴权不生效。
- 创建开启RBAC鉴权的Namespace后,需要先对用户授权后,用户才能使用这个Namespace。
- network、clusterRole和roleBinding资源不受RBAC权限影响,只受IAM细粒度鉴权控制。network受控于network相关action,clusterRole与roleBinding受控于rbac相关action。
- 支持对当前用户下的所有命名空间进行授权,以提供更好的前端显示体验。
- 如果同时基于IAM,授予系统角色(IAM RBAC授权)和授予自定义策略(IAM细粒度授权),则判定CCI权限的优先级顺序为:IAM RBAC授权>IAM细粒度授权。

命名空间权限
Kubernetes RBAC API定义了四种类型:Role、ClusterRole、RoleBinding与ClusterRoleBinding。当前CCI仅支持ClusterRole、RoleBinding,这两种类型之间的关系和简要说明如下:
- ClusterRole:描述角色和权限的关系。在Kubernetes的RBAC API中,一个角色定义了一组特定权限的规则。整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现。
- RoleBinding:描述subjects(包含users,groups)和角色的关系。角色绑定将一个角色中定义的各种权限授予一个或者一组用户,该用户或用户组则具有对应绑定ClusterRole定义的权限。
类型名称 |
说明 |
---|---|
ClusterRole |
ClusterRole对象可以授予整个集群范围内资源访问权限。 |
RoleBinding |
RoleBinding可以将同一Namespace中的subject(用户)绑定到某个具有特定权限的ClusterRole下,则此subject即具有该ClusterRole定义的权限。 |
当前仅支持用户使用ClusterRole在Namespace下创建RoleBinding。
CCI的kubernetes资源通过命名空间进行权限设置,目前包含cluster-admin、admin、edit、view四种角色,详见表2。
默认的ClusterRole |
描述 |
---|---|
cluster-admin |
具有Kubernetes所有资源对象操作权限。 |
admin |
允许admin访问,可以限制在一个Namespace中使用RoleBinding。如果在RoleBinding中使用,则允许对Namespace中大多数资源进行读写访问。这一角色不允许操作Namespace本身,也不能写入资源限额。 |
edit |
允许对命名空间内的大多数资源进行读写操作。 |
view |
允许对多数对象进行只读操作,但是对secret是不可访问的。 |
更多Kubernetes RBAC授权的内容可以参考Kubernetes RBAC官方文档。