Gestión de permisos
CCE le permite asignar permisos a los usuarios y grupos de usuarios de IAM en sus cuentas de tenant. CCE combina las ventajas de Identity and Access Management (IAM) y Kubernetes Role-based Access Control (RBAC) para proporcionar una variedad de métodos de autorización, incluida la autorización de grano fino/token de IAM y la autorización de ámbito de clúster/espacio de nombres.
- Cluster-level permissions: la gestión de permisos a nivel de clúster evoluciona de la función de autorización de políticas del sistema de IAM. Los usuarios de IAM del mismo grupo de usuarios tienen los mismos permisos. En IAM, puede configurar las políticas del sistema para describir qué grupos de usuarios de IAM pueden realizar las operaciones en los recursos del clúster. Por ejemplo, puede conceder al grupo de usuarios A que cree y elimine el clúster X, agregue un nodo o instale un complemento, mientras que concede al grupo de usuarios B que vea información sobre el clúster X.
Los permisos a nivel de clúster implican API de CCE que no son de Kubernetes y admiten las políticas de IAM detalladas y las capacidades de gestión de proyectos empresariales.
- Namespace-level permissions: puede regular el acceso de los usuarios o grupos de usuarios a los Kubernetes resources, como cargas de trabajo, trabajos y servicios, en un único espacio de nombres basado en sus roles RBAC de Kubernetes. El CCE también se ha mejorado sobre la base de las capacidades de código abierto. Admite la autorización de RBAC basada en el usuario o grupo de usuarios de IAM, y la autenticación de RBAC en el acceso a las API mediante tokens de IAM.
Los permisos a nivel de espacio de nombres implican API de CCE Kubernetes y se mejoran en función de las capacidades RBAC de Kubernetes. Los permisos de nivel de espacio de nombres se pueden conceder a los usuarios o grupos de usuarios de IAM para la autenticación y la autorización, pero son independientes de las políticas de IAM detalladas. Para obtener más información, consulte Uso de la autorización RBAC.
- Cluster-level permissionssolo se configuran para recursos relacionados con clústeres (como clústeres y nodos). También debe configurar los permisos de espacio de nombres para operar los recursos de Kubernetes (como cargas de trabajo, trabajos y servicios).
- Después de crear un clúster de v1.11.7-r2 o posterior, CCE le asigna automáticamente los permisos cluster-admin de todos los espacios de nombres del clúster, lo que significa que tiene control total sobre el clúster y todos los recursos de todos los espacios de nombres.
Permisos al nivel de clúster (asignados mediante políticas de sistema de IAM)
De forma predeterminada, los nuevos usuarios de IAM no tienen permisos asignados. Debe agregar un usuario a uno o más grupos y adjuntar políticas o roles de permisos a estos grupos. Los usuarios heredan permisos de los grupos a los que se agregan y pueden realizar operaciones específicas a servicios en la nube según los permisos.
CCE es un servicio a nivel de proyecto implementado y accedido en regiones físicas específicas. Para asignar los permisos de CCE a un grupo de usuarios, especifique el ámbito como proyectos específicos de la región y seleccione proyectos para que los permisos surtan efecto. Si se selecciona All projects, los permisos surtirán efecto para el grupo de usuarios en todos los proyectos específicos de la región. Al acceder a CCE, los usuarios deben cambiar a una región en la que se les haya autorizado a usar el servicio de CCE.
- Roles: Tipo de mecanismo de autorización de grano grueso que define permisos relacionados con las responsabilidades del usuario. Este mecanismo proporciona solo un número limitado de roles de nivel de servicio para la autorización. Al usar roles para asignar permisos, también debe asignar otros roles de los que dependen los permisos para que surtan efecto. Sin embargo, los roles no son una opción ideal para la autorización detallada y el control de acceso seguro.
- Políticas: Un tipo de mecanismo de autorización detallado que define los permisos necesarios para realizar operaciones en recursos de nube específicos bajo ciertas condiciones. Este mecanismo permite una autorización más flexible basada en políticas, cumpliendo los requisitos para un control de acceso seguro. Por ejemplo, puede asignar a los usuarios únicamente los permisos para gestionar un determinado tipo de clústeres y nodos.
Tabla 1 enumera todos los permisos del sistema admitidos por CCE.
Nombre de rol/política |
Descripción |
Tipo |
Dependencias |
|---|---|---|---|
CCE Administrator |
Permisos de lectura y escritura para clústeres de CCE y todos los recursos (incluidas cargas de trabajo, nodos, trabajos y servicios) en los clústeres |
Rol |
Los usuarios a los que se han concedido permisos de esta política también deben tener permisos de las siguientes políticas: Global service project: Visor de bucket de OBS y Administrador de OBS Region-specific projects: tenant invitado, administrador de servidor, administrador de ELB, administrador de SFS, administrador de SWR y FullAccess de APM
NOTA:
Los usuarios con políticas de CCE Administrator y NAT Gateway Administrator pueden usar funciones de NAT Gateway para clústeres. |
CCE FullAccess |
Permisos de operación comunes en los recursos de clúster de CCE, excluyendo los permisos a nivel de espacio de nombres para los clústeres (con Kubernetes RBAC habilitado) y las operaciones de administrador con privilegios, como la configuración de delegación y la generación de certificados de clúster |
Política |
No hay. |
CCE ReadOnlyAccess |
Permisos para ver los recursos del clúster de CCE, excluyendo los permisos a nivel de espacio de nombres de los clústeres (con Kubernetes RBAC habilitado) |
Política |
No hay. |
Operación |
CCE ReadOnlyAccess |
CCE FullAccess |
CCE Administrator |
|---|---|---|---|
Creación de un clúster |
x |
√ |
√ |
Eliminación de un clúster |
x |
√ |
√ |
Actualización de un clúster, por ejemplo, actualizar los parámetros de programación de nodos de clúster y proporcionar soporte RBAC a clústeres |
x |
√ |
√ |
Actualización de un clúster |
x |
√ |
√ |
Despierta de un clúster |
x |
√ |
√ |
Hibernación de un clúster |
x |
√ |
√ |
Listado de todos los clústeres |
√ |
√ |
√ |
Consulta de los detalles del clúster |
√ |
√ |
√ |
Adición de un nodo |
x |
√ |
√ |
Eliminación de uno o más nodos |
x |
√ |
√ |
Actualización de un nodo de clúster, por ejemplo, actualizar el nombre del nodo |
x |
√ |
√ |
Consulta de detalles de nodo |
√ |
√ |
√ |
Listado de todos los nodos |
√ |
√ |
√ |
Listado de todos los trabajos |
√ |
√ |
√ |
Supresión de uno o más trabajos de clúster |
x |
√ |
√ |
Consulta de detalles del trabajo |
√ |
√ |
√ |
Creación de un volumen de almacenamiento |
x |
√ |
√ |
Eliminación de un volumen de almacenamiento |
x |
√ |
√ |
Realización de operaciones en todos los recursos de Kubernetes |
√ |
√ |
√ |
Realización de todas las operaciones en un Elastic Cloud Server (ECS) |
x |
√ |
√ |
Realización de todas las operaciones en discos de Elastic Volume Service (EVS) Los discos de EVS se pueden conectar a servidores en la nube y escalar a una mayor capacidad cuando sea necesario. |
x |
√ |
√ |
Realización de todas las operaciones en VPC Un clúster debe ejecutarse en una VPC. Al crear un espacio de nombres, debe crear o asociar una VPC para el espacio de nombres de modo que todos los contenedores del espacio de nombres se ejecuten en la VPC. |
x |
√ |
√ |
Consulta de detalles de todos los recursos en un ECS En CCE, un nodo es un ECS con múltiples discos de EVS. |
√ |
√ |
√ |
Listado de todos los recursos en un ECS |
√ |
√ |
√ |
Consulta de detalles sobre todos los recursos de discos de EVS. Los discos de EVS se pueden conectar a los servidores en la nube y escalar a una mayor capacidad siempre que sea necesario. |
√ |
√ |
√ |
Listado de todos los recursos de EVS |
√ |
√ |
√ |
Consulta de detalles sobre todos los recursos de VPC Un clúster debe ejecutarse en una VPC. Al crear un espacio de nombres, debe crear o asociar una VPC para el espacio de nombres de modo que todos los contenedores del espacio de nombres se ejecuten en la VPC. |
√ |
√ |
√ |
Listado de todos los recursos de VPC |
√ |
√ |
√ |
Consulta de detalles sobre todos los recursos de Elastic Load Balance (ELB) |
x |
x |
√ |
Listado de todos los recursos de ELB |
x |
x |
√ |
Consulta de los detalles de recursos del Scalable File Service (SFS) |
√ |
√ |
√ |
Listado de todos los recursos de SFS |
√ |
√ |
√ |
Consulta de los detalles de recursos de Application Operations Management (AOM) |
√ |
√ |
√ |
Listado de recursos de AOM |
√ |
√ |
√ |
Realización de todas las operaciones en reglas de ajuste automático de AOM |
√ |
√ |
√ |
Permisos a nivel de espacio de nombres (asignados mediante Kubernetes RBAC)
Puede regular el acceso de los usuarios o los grupos de usuarios a los recursos de Kubernetes en un único espacio de nombres basado en sus roles de Kubernetes RBAC. La API de RBAC declara cuatro tipos de objetos de Kubernetes: Role, ClusterRole, RoleBinding y ClusterRoleBinding, que se describen a continuación:
- Role: define un conjunto de reglas para acceder a los recursos de Kubernetes en un espacio de nombres.
- RoleBinding: define la relación entre usuarios y roles.
- ClusterRole define un conjunto de reglas para acceder a los recursos de Kubernetes en un clúster (incluidos todos los espacios de nombres).
- ClusterRoleBinding: define la relación entre los usuarios y los roles de clúster.
Role y ClusterRole especifican acciones que se pueden realizar en recursos específicos. RoleBinding y ClusterRoleBinding vinculan roles a usuarios específicos, grupos de usuarios o cuentas de servicio. Consulta la siguiente figura.
En la consola de CCE, puede asignar permisos a un usuario o grupo de usuarios para tener acceso a recursos en uno o varios espacios de nombres. De forma predeterminada, la consola de CCE proporciona las siguientes ClusterRoles:
- view: tiene permiso para ver recursos de espacio de nombres.
- edit: tiene permiso para modificar los recursos del espacio de nombres.
- admin: tiene todos los permisos en el espacio de nombres.
- cluster-admin: tiene todos los permisos en el clúster.
- psp-global: controla aspectos de seguridad sensibles de la especificación del pod.
Además de cluster-admin, admin, edit, y view, puede definir Roles y RoleBindings para configurar los permisos para agregar, eliminar, modificar y consultar recursos, como pods, implementaciones y servicios, en el espacio de nombres.
