Configuración de políticas para despliegue y creación de clusters

Descubra las políticas de IAM que debe crear antes de utilizar Container Engine for Kubernetes (OKE).

Cuando se crea un arrendamiento, se crea automáticamente un grupo de Administradores para el arrendamiento. Los usuarios que son miembros del grupo de Administradores pueden realizar cualquier operación en los recursos del arrendamiento. Si todos los usuarios que van a trabajar con Container Engine for Kubernetes ya son miembros del grupo Administradores, no hay necesidad de crear otras políticas.

Sin embargo, si desea permitir que los usuarios que no sean miembros del grupo de Administradores utilicen Container Engine for Kubernetes, debe crear políticas para activar los grupos a los que pertenecen esos usuarios para realizar operaciones en recursos del arrendamiento o en compartimentos individuales. Algunas políticas son necesarias; otras son opcionales. Consulte Creación de políticas necesarias para grupos y Creación de una o más políticas adicionales para grupos.

También debe crear políticas adicionales si desea:

Cree y utilice clusters con nodos virtuales y pools de nodos virtuales. Consulte Creación de una política para configurar y utilizar nodos virtuales.
Cifre los datos en volúmenes de inicio y volúmenes en bloque mediante sus propias claves de cifrado maestras desde el servicio Almacén. Consulte Create Policy to Access User-Managed Encryption Keys for Encrypting Boot Volumes, Block Volumes, and/o File Systems.

Si desea que los grupos de usuarios de un arrendamiento accedan a recursos relacionados con el cluster en otros arrendamientos, debe crear sentencias de política especiales entre arrendamientos que establezcan explícitamente los recursos a los que se puede acceder y compartir. Consulte Acceso a recursos relacionados con clusters en arrendamientos.

Tenga en cuenta que, además de las políticas anteriores gestionadas por IAM, también puede utilizar el responsable de autorización de Kubernetes RBAC para aplicar control de acceso detallado adicional para usuarios en clusters específicos a través de Clusterroles y Roles de Kubernetes RBAC. Consulte Acerca de control de acceso y Container Engine for Kubernetes.

Crear política necesaria para grupos

Para crear, actualizar y suprimir clusters y pools de nodos, los usuarios que no sean miembros del grupo de Administradores deben tener permisos para trabajar con recursos relacionados con clusters. Para otorgar a los usuarios el acceso necesario, debe crear una política con un número de sentencias de política necesarias para los grupos a los que pertenecen los usuarios:

Abra el menú de navegación y haga clic en Identidad y seguridad. En Identidad, haga clic en Políticas. Se muestra una lista de políticas en el compartimento que está viendo.
Seleccione el compartimento raíz del arrendamiento o un compartimento individual que contenga recursos relacionados con el cluster de la lista de la izquierda.
Haga clic en Crear política.
Introduzca lo siguiente:
- Nombre: nombre de la política (por ejemplo, acme-dev-team-oke-required-policy) que es exclusivo dentro del compartimento. Si está creando la política en el compartimento raíz del arrendamiento, el nombre debe ser exclusivo en todas las políticas del arrendamiento. Luego no podrá cambiarlo. Evite introducir información confidencial.
- Descripción: descripción fácil de recordar. Puede cambiarla más tarde si lo desea.
- Sentencia: las siguientes sentencias de políticas necesarias permiten a los usuarios utilizar Container Engine for Kubernetes para crear, actualizar y suprimir clusters y pools de nodos:
```
Allow group <group-name> to manage instance-family in <location>
```
```
Allow group <group-name> to use subnets in <location>
```
```
Allow group <group-name> to manage virtual-network-family in <location>
```
```
Allow group <group-name> to inspect compartments in <location>
```
```
Allow group <group-name> to use vnics in <location>
```
```
Allow group <group-name> to use network-security-groups  in <location>
```
```
Allow group <group-name> to use private-ips  in <location>
```
```
Allow group <group-name> to manage public-ips  in <location>
```
  La siguiente sentencia de política necesaria para permitir a los usuarios realizar cualquier operación en recursos relacionados con clusters (esta política "catch-all" hace que todos los usuarios sean administradores hasta la fecha en cuanto a recursos relacionados con el cluster se refiere):
```
Allow group <group-name> to manage cluster-family in <location>
```
  En las sentencias de política anteriores, sustituya <location> por tenancy (si está creando la política en el compartimento raíz del arrendamiento) o compartment <compartment-name> (si está creando la política en un compartimento individual).
  Nota
  
  Tenga en cuenta que, según el tipo de cluster, puede que algunas sentencias de política necesarias no lo sean:
  - Para trabajar con clusters "nativos de VCN" (donde el punto final de API de Kubernetes está totalmente integrado con la VCN), siempre se necesita use private-ips. Sin embargo, la sentencia de política use public-ips solo es necesaria si se selecciona la opción de dirección IP pública de los clusters. Para obtener más información sobre los clusters nativos de VCN, consulte Plano de control de cluster de Kubernetes y API de Kubernetes.
  - Para trabajar con clusters en los que el punto final de API de Kubernetes pública está en un arrendamiento gestionado por Oracle, las sentencias de política use vnics, use private-ips y use public-ips no son necesarias.
  Tenga en cuenta que si un grupo no está en el dominio de identidad por defecto, agregue un prefijo al nombre de grupo con el nombre de dominio de identidad, con el formato group '<identity-domain-name>'/'group-name'. También puede especificar un grupo mediante su OCID, con el formato group id <group-ocid>.
- Etiquetas: si tiene permiso para crear un recurso, también tendrá permiso para aplicar etiquetas de formato libre a dicho recurso. Para aplicar una etiqueta definida, debe tener permisos para utilizar el espacio de nombres de etiqueta. Para obtener más información sobre el etiquetado, consulte Etiquetas de recursos. Si no está seguro de si desea aplicar etiquetas, omita esta opción o pregunte a un administrador. Puede aplicar las etiquetas más tarde.
Haga clic en Crear.

Creación de una o más políticas adicionales para grupos

Para permitir que los usuarios que no son miembros del grupo de Administradores utilicen Container Engine for Kubernetes, cree políticas adicionales para activar los grupos a los que pertenecen los usuarios para realizar operaciones en recursos relacionados con el cluster de la siguiente forma:

Abra el menú de navegación y haga clic en Identidad y seguridad. En Identidad, haga clic en Políticas. Se muestra una lista de políticas en el compartimento que está viendo.
Seleccione el compartimento raíz del arrendamiento o un compartimento individual que contenga recursos relacionados con el cluster de la lista de la izquierda.
Haga clic en Crear política.
Introduzca lo siguiente:
- Nombre: nombre de la política (por ejemplo, acme-dev-team-oke-additional-policy) que es exclusivo dentro del compartimento. Si está creando la política en el compartimento raíz del arrendamiento, el nombre debe ser exclusivo en todas las políticas del arrendamiento. Luego no podrá cambiarlo. Evite introducir información confidencial.
- Descripción: descripción fácil de recordar. Puede cambiarla más tarde si lo desea.
- Sentencia: sentencia de política adecuada para permitir a los grupos existentes realizar operaciones en recursos relacionados con clusters. En las siguientes sentencias de política de ejemplo, sustituya <location> por tenancy (si está creando la política en el compartimento raíz del arrendamiento) o compartment <compartment-name> (si está creando la política en un compartimento individual):
  - Para permitir que los usuarios del grupo acme-dev-team creen y configuren automáticamente nuevos recursos de red asociados al crear nuevos clusters en el flujo de trabajo "Creación rápida", las políticas también deben otorgar al grupo:
    - permisos VCN_READ y VCN_CREATE. Introduzca una sentencia de política como la siguiente:
      Allow group acme-dev-team to manage vcns in <location>
    - permisos SUBNET_READ y SUBNET_CREATE. Introduzca una sentencia de política como la siguiente:
      Allow group acme-dev-team to manage subnets in <location>
    - permiso INTERNET_GATEWAY_CREATE. Introduzca una sentencia de política como la siguiente:
      Allow group acme-dev-team to manage internet-gateways in <location>
    - permiso NAT_GATEWAY_CREATE. Introduzca una sentencia de política como la siguiente:
      Allow group acme-dev-team to manage nat-gateways in <location>
    - permiso ROUTE_TABLE_UPDATE. Introduzca una sentencia de política como la siguiente:
      Allow group acme-dev-team to manage route-tables in <location>
    - permiso SECURITY_LIST_CREATE. Introduzca una sentencia de política como la siguiente:
      Allow group acme-dev-team to manage security-lists in <location>
  - Para permitir que los usuarios del grupo acme-dev-team-cluster-viewers muestren simplemente los clusters, introduzca una sentencia de política como la siguiente:
```
Allow group acme-dev-team-cluster-viewers to inspect clusters in <location>
```
  - Para permitir que los usuarios del grupo acme-dev-team-pool-admins muestren, creen, actualicen y supriman pools de nodos, introduzca una sentencia de política como la siguiente:
```
Allow group acme-dev-team-pool-admins to use cluster-node-pools in <location>
```
  - Para permitir a los usuarios del grupo acme-dev-team-auditors vean los detalles de las operaciones realizadas en clusters, introduzca una sentencia de política como la siguiente:
```
Allow group acme-dev-team-auditors to read cluster-work-requests in <location>
```
  - Para permitir que los usuarios del grupo acme-dev-team-sgw creen un gateway de servicio que permita a los nodos de trabajador acceder a otros recursos de la misma región sin exponer datos a la red pública de Internet, introduzca una sentencia de política como la siguiente:
```
Allow group acme-dev-team-sgw to manage service-gateways in <location>
```
  - Para permitir que los usuarios del grupoacme-dev-team accedan a clusters mediante Cloud Shell, introduzca una sentencia de política como la siguiente:
```
Allow group acme-dev-team to use cloud-shell in <location>
```
    Tenga en cuenta que para acceder a los clusters mediante Cloud Shell, también tendrá que configurar el archivo kubeconfig de forma adecuada (consulte Configuración del acceso de Cloud Shell a los clusters). Para obtener más información sobre Cloud Shell, consulte Cloud Shell.
  - Para permitir que los usuarios del grupo acme-dev-team seleccionen claves de cifrado maestras y almacenes en el servicio Almacén al crear y modificar clusters mediante la consola:
```
Allow group acme-dev-team to read vaults in <location>
```
```
Allow group acme-dev-team to read keys in <location>
```
  - Para permitir que los usuarios del grupo acme-dev-team utilicen reservas de capacidad:
```
Allow group acme-dev-team to use compute-capacity-reservations in <location>
```
    Para obtener más información, consulte Uso de reservas de capacidad para aprovisionar nodos gestionados
  Nota
  
  Tenga en cuenta que si un grupo no está en el dominio de identidad por defecto, agregue un prefijo al nombre de grupo con el nombre de dominio de identidad, con el formato group '<identity-domain-name>'/'group-name'. También puede especificar un grupo mediante su OCID, con el formato group id <group-ocid>.
- Etiquetas: si tiene permiso para crear un recurso, también tendrá permiso para aplicar etiquetas de formato libre a dicho recurso. Para aplicar una etiqueta definida, debe tener permisos para utilizar el espacio de nombres de etiqueta. Para obtener más información sobre el etiquetado, consulte Etiquetas de recursos. Si no está seguro de si desea aplicar etiquetas, omita esta opción o pregunte a un administrador. Puede aplicar las etiquetas más tarde.
Haga clic en Crear.

Creación de una política para configurar y utilizar nodos virtuales

Para crear y utilizar clusters con nodos virtuales y pools de nodos virtuales, siempre debe configurar al menos una política de IAM, que es necesaria en todas las circunstancias tanto para los administradores del arrendamiento como para los usuarios que no sean administradores. Para permitir que los usuarios que no son administradores utilicen nodos virtuales, también debe configurar una política adicional. En resumen, las políticas:

Apruebe el servicio Container Engine for Kubernetes para permitir que los nodos virtuales creen instancias de contenedor en el arrendamiento del servicio Container Engine for Kubernetes con una VNIC conectada a una subred de una VCN de su arrendamiento.
Otorgue a los usuarios que no sean administradores los permisos necesarios.

Para obtener más información sobre las sentencias de política que se van a introducir, consulte Políticas de IAM necesarias para utilizar nodos virtuales.

Creación de una política para acceder a las claves de cifrado gestionadas por el usuario para el cifrado de volúmenes de inicio, volúmenes en bloque y/o sistemas de archivos

Para especificar una clave de cifrado maestra gestionada por el usuario concreta del servicio Almacén para cifrar datos en volúmenes de inicio, volúmenes en bloque y/o sistemas de archivos, debe crear una política para permitir el acceso a esa clave de cifrado maestra. Para obtener más información sobre la especificación de claves de cifrado gestionadas por el usuario:

para volúmenes de inicio, consulte Uso de la consola para crear un cluster con valores definidos explícitamente en el flujo de trabajo "Creación personalizada" y Modificación de propiedades de pool de nodos y nodo de trabajador según corresponda.
para volúmenes en bloque, consulte Cifrado de datos estáticos y datos en tránsito con el servicio de volúmenes en bloque
para sistemas de archivos, consulte Cifrado de datos estáticos y datos en tránsito con el servicio de almacenamiento de archivos

Tenga en cuenta que antes de crear la política, debe conocer el OCID de la clave de cifrado maestra (consulte Gestión de claves).

Para crear una política que permita el acceso a una clave de cifrado maestra gestionada por el usuario:

Abra el menú de navegación y haga clic en Identidad y seguridad. En Identidad, haga clic en Políticas. Se muestra una lista de políticas en el compartimento que está viendo.
Se muestra una lista de políticas en el compartimento que está viendo.
Seleccione el compartimento raíz del arrendamiento o un compartimento individual que contenga recursos relacionados con el cluster de la lista de la izquierda.
Haga clic en Crear política, siga las instrucciones de Para crear una política y asigne un nombre a la política (por ejemplo, acme-oke-keys-policy).
Para volúmenes de inicio: para utilizar una clave de cifrado maestra del servicio Vault para cifrar datos en volúmenes de inicio, introduzca las siguientes sentencias de política para otorgar acceso a la clave de cifrado maestra:
```
Allow group <group-name> to read keys in compartment <compartment-name> where target.key.id = '<key_OCID>'
```
```
Allow service oke to use key-delegates in compartment <compartment-name> where target.key.id = '<key_OCID>'
```
```
Allow service blockstorage to use keys in compartment <compartment-name> where target.key.id = '<key_OCID>'
```
donde:
- <group-name> es un grupo al que pertenece. Tenga en cuenta que si un grupo no está en el dominio de identidad por defecto, agregue un prefijo al nombre de grupo con el nombre de dominio de identidad, con el formato group '<identity-domain-name>'/'group-name'. También puede especificar un grupo mediante su OCID, con el formato group id <group-ocid>.
- <compartment-name> es el nombre del compartimento que contiene la clave de cifrado maestra.
- <key-OCID> es el OCID de la clave de cifrado maestra del almacén de claves.
Por ejemplo:
```
Allow group acme-dev-team to read keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
Allow service oke to use key-delegates in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
Allow service blockstorage to use keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
```

Para volúmenes en bloque: para utilizar una clave de cifrado maestra del servicio Vault para cifrar datos en volúmenes en bloque, introduzca sentencias de política para otorgar acceso a la clave de cifrado maestra con el formato:

Allow service blockstorage to use keys in compartment <compartment-name> where target.key.id = '<key-ocid>'


Allow any-user to use key-delegates in compartment <compartment-name> where ALL {request.principal.type = 'cluster', target.key.id = '<key-ocid>'}

donde:

<compartment-name> es el nombre del compartimento que contiene la clave de cifrado maestra.
<key-OCID> es el OCID de la clave de cifrado maestra del almacén de claves.

Por ejemplo:

Allow service blockstorage to use keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
Allow any-user to use key-delegates in compartment acme-kms-key-compartment where ALL {request.principal.type = 'cluster', target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'}

Para sistemas de archivos: para utilizar una clave de cifrado maestra del servicio Vault para cifrar datos en sistemas de archivos, introduzca sentencias de política para otorgar acceso a la clave de cifrado maestra con el formato:
```
Allow dynamic-group <dynamic-group-name> to use keys in compartment <key-compartment-name>
```
```
Allow any-user to use key-delegates in compartment <compartment-name> where ALL {request.principal.type = 'cluster', target.key.id = '<key_OCID>'}
```
donde:
- <dynamic-group-name> es el nombre del grupo dinámico de los sistemas de archivos del compartimento.
  
  A continuación se muestra una regla de ejemplo para el grupo dinámico:
```
ALL { resource.type='filesystem', resource.compartment.id = '<file_system_compartment_OCID>' }
```
  Tenga en cuenta que si un grupo dinámico no está en el dominio de identidad por defecto, agregue un prefijo al nombre de grupo dinámico con el nombre de dominio de identidad, con el formato dynamic-group '<identity-domain-name>'/'<dynamic-group-name>'. También puede especificar el grupo dinámico mediante su OCID, con el formato dynamic-group id <dynamic-group-ocid>.
- <compartment-name> es el nombre del compartimento que contiene la clave de cifrado maestra.
- <key_OCID> es el OCID de la clave de cifrado maestra del almacén de datos de Vault.
Por ejemplo:
```
Allow dynamic-group FssFileSystems to use keys in compartment acme-kms-key-compartment
Allow any-user to use key-delegates in compartment acme-kms-key-compartment where ALL {request.principal.type = 'cluster', target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'}
```
Haga clic en Crear.

Documentación de Oracle Cloud Infrastructure

Configuración de políticas para despliegue y creación de clusters

Crear política necesaria para grupos

Creación de una o más políticas adicionales para grupos

Creación de una política para configurar y utilizar nodos virtuales

Creación de una política para acceder a las claves de cifrado gestionadas por el usuario para el cifrado de volúmenes de inicio, volúmenes en bloque y/o sistemas de archivos