Utilizar perfiles de confianza como base para entornos cloud seguros
Esta guía de aprendizaje puede incurrir en costes. Utilice Estimador de costes para generar una estimación del coste basada en el uso previsto.
IBM Cloud Identity and Access Management(IAM) le permite controlar qué usuarios ven, crean, utilizan y gestionan recursos en el entorno de nube. Su entorno puede ser una única cuenta de IBM Cloud, varias cuentas o una empresa con una jerarquía de muchos grupos de cuentas y cuentas. Al operar con recursos de cuenta, a menudo, los usuarios y los ID de servicio están implicados. Sin embargo, hay más opciones disponibles para gestionar el acceso, asignar privilegios e identificar: Perfiles de confianza.
En esta guía de aprendizaje, aprenderá sobre los perfiles de confianza, sus casos de uso y cómo utilizarlos para mejorar la seguridad. Los perfiles de confianza pueden servir como base para entornos cloud seguros, como componente básico para soluciones cloud seguras. Como parte de esta guía de aprendizaje, creará un perfil de confianza que utilizará una aplicación para realizar tareas administrativas.
Objetivos
- Más información sobre casos de uso para perfiles de confianza
- Cree perfiles de confianza y gestione el acceso a los recursos de cloud
- Profundizar en sus conocimientos de gestión de identidades y accesos ( Identity and Access Management, IAM)
- La imagen de contenedor para la aplicación se extrae de Container Registry y se despliega en el clúster Kubernetes en un espacio de nombres.
- El usuario se conecta a la aplicación.
- La aplicación lee una señal de acceso especial del entorno Kubernetes y la convierte en una señal de acceso de IAM para un perfil de confianza.
- IAM registra los eventos de auditoría en IBM Cloud Activity Tracker Event Routing.
Antes de empezar
Esta guía de aprendizaje no requiere ninguna instalación y sólo utiliza la consola deIBM Cloud.
El IBM Cloud Activity Tracker Event Routing debe estar configurado para enrutar los eventos de auditoría a una IBM Cloud Logs instancia de destino. Enrute los eventos de auditoría global como se describe en la configuración de un objetivo IBM Logs si no está configurado actualmente en su cuenta.
Visión general: Perfiles de confianza
De forma similar a los usuarios y los ID de servicio, los perfiles de confianza son identidades a las que se puede otorgar acceso en las políticas de IAM. Los perfiles de confianza difieren en que no pueden crear y poseer claves de API. Son una identidad dentro de una cuenta específica que sirve como "pasarela" para que alguien o algo más trabaje dentro de esa cuenta sin necesidad de una clave de API. Pueden asumir la identidad de ese perfil de confianza.
Puede configurar esa persona o algo más (consulte a continuación) como parte de la configuración del perfil de confianza. Todas las opciones habituales están disponibles, la API de IBM Cloud, la CLI, cualquiera de los SDK disponibles, Terraform o la consola de IBM Cloud.
En la consola, como parte de la categoría IAM, los perfiles de confianza tienen su propia sección. Allí, puede crearlos y gestionarlos fácilmente. La siguiente captura de pantalla muestra el segundo paso del diálogo para crear un perfil de confianza. Puede configurar cómo establecer la confianza, qué entidad puede asumir la identidad del perfil de confianza. Es uno o más de los siguientes:
- Usuarios federados
- Recursos de cálculo
- Servicios de IBM Cloud
- ID de servicio
Casos de uso de perfil de confianza
Los perfiles de confianza son identidades dentro de IBM Cloud. Pueden ser miembros de grupos de acceso de IAM y, por lo tanto, tienen privilegios de acceso asignados. Al igual que los usuarios y los ID de servicio, también puede asignar directamente acceso a perfiles de confianza. La característica distintiva es la capacidad de configurar un perfil de confianza, para que identidades o recursos específicos puedan actuar bajo su identidad. Estas identidades y recursos pueden estar incluso ubicados en otras cuentas. Por lo tanto, en un nivel alto, el caso de uso de para utilizar perfiles de confianza es permitir el trabajo administrativo
- con un conjunto determinado de privilegios
- bajo una identidad específica
- para identidades o recursos identificados por un conjunto de propiedades configuradas como parte del perfil de confianza.
Los escenarios siguientes son tales casos de uso para perfiles de confianza, que difieren por la forma en que se establece la confianza:
- Correlacionar usuarios federados y su pertenencia a grupos con privilegios de IBM Cloud: configure un perfil de confianza para permitir que los usuarios de un proveedor de identidades federadas asuman su identidad. Puede definir qué IdP y qué atributos de usuario se deben tener en cuenta.
- Realizar tareas administrativas desde recursos de cálculo dedicados: puede configurar un perfil de confianza para establecer la confianza a través de un recurso de cálculo conocido. Este recurso puede ser un pod específico en un clúster de Kubernetes (incluido Red Hat OpenShift on IBM Cloud) o una instancia de servidor virtual (VSI) en una nube privada virtual (IBM Cloud VPC).
- Realizar tareas administrativas desde un ID de servicio conocido: un ID de servicio de la misma cuenta o de otra cuenta puede asumir la identidad del perfil de confianza.
- Desplegar recursos de nube desde una instancia de un servicio de nube especial: Configure una instancia de un servicio IBM Cloud, identificado por su CRN (nombre de recurso de nube) para que pueda asumir la identidad de un perfil de confianza. Un escenario típico es que un proyecto empresarial de despliegue una arquitectura.
Establecer confianza
Como se describe en la visión general, hay diferentes opciones disponibles sobre cómo establecer la confianza, cómo una entidad puede asumir la identidad de un perfil de confianza.
Identidad federada
Los usuarios que utilizan un ID de inicio de sesión único corporativo o empresarial para iniciar sesión en IBM Cloud se denominan identidades federadas. El proveedor de inicio de sesión único (SSO) actúa como proveedor de identidad (IdP). Una gran ventaja de utilizar identidades federadas es que los usuarios de no necesitan nuevas credenciales para utilizarlas con IBM Cloud y pueden seguir utilizando el IdP de sus empresas para la autenticación.
Las identidades federadas se pueden utilizar con perfiles de confianza y en reglas dinámicas de grupos de acceso de IAM.
recurso de cálculo
En lugar de a través de las propiedades de usuario proporcionadas por un proveedor de identidad, en este caso, la confianza se establece a través de atributos de recursos de cálculo. Puede configurar que solo confíe en una app que se ejecute en, por ejemplo, un espacio de nombres y pod específicos en un clúster de Kubernetes, o una instancia de servidor virtual en una VPC con una combinación específica de valores para grupo de recursos, región, subred y zona. Dicha app de confianza puede asumir la identidad del perfil de confianza y realizar tareas con los privilegios asignados.
La ventaja de utilizar un perfil de confianza basado en un recurso de cálculo es que esta solución evita utilizar una clave de API. Por lo tanto, no hay requisitos y retos sobre cómo crear, almacenar y proteger cualquier clave de API compartida, cómo asignar y gestionar privilegios. La app que presupone la identidad de un perfil de confianza simplemente capta una señal de recurso de cálculo especial y, a continuación, la convierte en una señal de acceso de IAM normal para el perfil de confianza. A partir de entonces, las tareas previstas se pueden realizar con la señal proporcionada para la autenticación.
Consulte la publicación del blog Developer Tricks: Simulate Cloud Security for Local App Development para obtener más información sobre la señal de recurso de cálculo. Aprenda a desarrollar y probar localmente aplicaciones que utilizan esa señal.
ID de servicio
Otro método para establecer la confianza es especificando un ID de servicio. El ID de servicio puede ser de la misma cuenta o de otra. Puesto que los ID de servicio son identidades exclusivas en todas las cuentas de IBM Cloud, no es necesario configurar más atributos. Con esa configuración en su lugar, un ID de servicio de una cuenta A ahora puede solicitar asumir la identidad de un perfil de confianza en la cuenta B y realizar tareas (administrativas).
Instancia de servicio en la nube
De forma similar a un ID de servicio, es posible especificar el nombre de recurso de nube (CRN) de una instancia de servicio de IBM Cloud, para que la instancia sea un recurso de confianza. Esa instancia de servicio puede estar ubicada en la misma cuenta o en otra. En este momento, su único escenario soportado es que un proyecto empresarial de despliegue una arquitectura. Los proyectos, como instancias de servicio, con arquitecturas desplegables se pueden gestionar de forma centralizada en una cuenta. Al establecer la confianza a través del CRN del proyecto, puede asumir la identidad de un perfil de confianza en otra cuenta de la misma o de otra jerarquía de cuentas de empresa y, a continuación, desplegar un patrón de solución con sus recursos.
Perfil de confianza con recurso de cálculo
Para poner en práctica la teoría, vas a autorizar a una app en contenedor a realizar tareas en una cuenta IBM Cloud. La aplicación se implementa en un clúster de Amazon Web Services ( Kubernetes ). Sirve como recurso de cálculo que se va a utilizar para establecer la confianza para utilizar el perfil de confianza. Puede realizar todos los pasos siguientes en un navegador web con varios separadores abiertos. Asegúrese de dejar abiertas las pestañas del navegador tal como se indica.
Por motivos de seguridad, la aplicación está funcionando en una modalidad de sólo lectura. Intenta recopilar una lista de los recursos desplegados. Asignará privilegios a la aplicación que determinan qué recursos puede leer. Además, desplegará la app de una forma, para que sea accesible solo desde el clúster de Kubernetes, no desde Internet público.
La publicación de blog Turn Your Container Into a Trusted Cloud Identity describe el mismo escenario.
Clúster de Kubernetes como recurso de cálculo
Kubernetes Service proporciona un entorno para desplegar apps de alta disponibilidad en contenedores que se ejecutan en clústeres de Kubernetes.
Omita esta sección si ya tiene un clúster que desea reutilizar con este tutorial. A lo largo del resto de este tutorial, se hace referencia al nombre del clúster como mycluster-tpcr, simplemente sustitúyalo por el nombre de su clúster. Tenga en cuenta que la versión mínima requerida de Kubernetes es 1.21.
Un clúster mínimo con una (1) zona, un (1) nodo trabajador y el menor tamaño disponible (Tipo) son suficientes para esta guía de aprendizaje. Se requiere una versión mínima de Kubernetes de 1.21. Asegúrese de seleccionar una versión adecuada cuando cree el clúster.
Abra los clústeres deKubernetes y pulse Crear clúster. Consulte la documentación a la que se hace referencia a continuación para obtener más detalles en función del tipo de clúster. Resumen:
- Haga clic en Grupo de nivel estándar
- Para Kubernetes en la infraestructura de VPC, consulte la documentación de referencia Creación de clústeres de VPC.
- Pulse Crear VPC:
- Introduzca un nombre para el VPC.
- Elija el mismo grupo de recursos que el clúster.
- Pulse Crear.
- Conecte una Public Gateway a cada una de las subredes que cree:
- Vaya a Nubes privadas virtuales.
- Pulse la VPC creada anteriormente utilizada para el clúster.
- Desplácese hacia abajo hasta la sección de subredes y pulse una subred.
- En la sección Public Gateway, pulse Desconectado para cambiar el estado a Conectado.
- Pulse el botón Atrás del navegador para volver a la página de detalles de VPC.
- Repita los tres pasos anteriores para conectar una pasarela pública a cada subred.
- Pulse Crear VPC:
- Para Kubernetes en la infraestructura clásica, consulte la documentación de referencia Creación de un clúster clásico.
- Elija un grupo de recursos.
- Desmarque todas las zonas excepto una.
- Reduzca a 1 Nodos de trabajador por zona.
- Elija el Tipo de agrupación de trabajadores más pequeño.
- Para el Nombre de clúster, utilice mycluster-tpcr.
- Desactive todas las opciones de seguridad para este clúster de demostración que se eliminará después de completar este tutorial. Será importante evaluarlas cuidadosamente para otras agrupaciones que cree.
Cuando se suministre el clúster, deje el separador del navegador (visión general del clúster) abierto y disponible para más adelante. No obstante, puede pasar a los siguientes pasos.
Crear un perfil de confianza
- En una nueva pestaña del navegador (Perfil de confianza de IAM), utilice la navegación superior Gestionar > Access (IAM) y, a continuación, Perfiles de confianza a la izquierda para obtener la visión general de los perfiles de confianza. A continuación, cree un nuevo perfil de confianza.
- Utilice TPwithCR como Nombre y escriba una breve Descripción, por ejemplo,
Test trusted profile with compute resource. A continuación, pulse Continuar. - En la segunda pestaña de formulario, en Seleccionar tipo de entidad de confianza, seleccione Calcular recursos y aparecerá un diálogo Crear relación de confianza. Allí, elija Kubernetes como Tipo de servicio de cálculo.
- A continuación, puede decidir entre todos o recursos de servicio específicos.
- Pulse Recursos específicos y aparecerá el siguiente campo de formulario.
- En Especifique o seleccione una instancia, pulse Añadir recurso. A continuación, en el campo Permitir acceso a, seleccione el clúster de Kubernetes mycluster-tpcr.
- A continuación, especifique tptest como valor para Espacio de nombres. Deje el campo para Cuenta de servicio tal cual para ir con el valor predeterminado.
- Termina haciendo clic en Continuar.
- A continuación, pulse Política de acceso. En la lista de servicios, seleccione Todos los servicios habilitados para identidad y acceso y pulse Siguiente. Vaya con Todos los recursos, pulse Siguiente de nuevo, seleccione Visor y pulse de nuevo en Siguiente. En la sección Roles y acciones, seleccione Lector para Acceso de servicio y Visor para Acceso de plataforma. Cuando haya terminado, pulse Siguiente y, finalmente, Añadir.
- Revise el Resumen a la derecha y, a continuación, Cree el perfil de confianza con la relación de confianza mostrada y los privilegios de acceso listados. Deje abierta la pestaña del navegador para más adelante.
La utilización de un grupo de acceso para asignar acceso es una práctica recomendable. En aras de la simplicidad, optamos por asignar acceso de sólo lectura a través de una política de acceso directo. La recomendación es crear un grupo de acceso con privilegios asignados y, a continuación, hacer que el perfil de confianza sea miembro del mismo.
Despliegue de la app
Con el clúster de Kubernetes y el perfil de confianza en su lugar, es el momento de desplegar una app de prueba simple. El código fuente de la app y la configuración se encuentra en el repositorio GitHub trusted-profile-enterprise-security. No lo necesita para el despliegue, pero podría estar interesado en cómo funciona no obstante.
-
En la pestaña del navegador visión general del clúster, compruebe que el clúster se ha desplegado por completo. En una configuración de un nodo, el estado de entrada puede informar de una advertencia. Es posible que desee actualizar el navegador y comprobar que otras marcas de verificación son de color verde. Si este es el caso, pulse en el panel de control deKubernetes y se abrirá un nuevo separador del navegador (panel de control deKubernetes).
-
En la parte superior izquierda, busque el selector de espacio de nombres y cambie a Todos los espacios de nombres.
-
En la parte superior derecha, pulse + para crear un recurso nuevo. Pegue el contenido siguiente en el formulario de texto Crear a partir de entrada.
apiVersion: v1 kind: Namespace metadata: name: tptest labels: name: tptest --- apiVersion: v1 kind: Service metadata: name: trustedprofile-test namespace: tptest spec: ports: - port: 8080 targetPort: 8080 protocol: TCP type: ClusterIP selector: app: tptest --- apiVersion: apps/v1 kind: Deployment metadata: name: trustedprofile-test-deployment namespace: tptest spec: selector: matchLabels: app: tptest replicas: 1 template: metadata: labels: app: tptest spec: containers: - name: tptest-container image: icr.io/solution-tutorials/tutorial-trusted-profile-enterprise-security:v1.0.3 imagePullPolicy: Always ports: - containerPort: 8080 volumeMounts: - mountPath: /var/run/secrets/tokens name: sa-token serviceAccountName: default volumes: - name: sa-token projected: sources: - serviceAccountToken: path: sa-token expirationSeconds: 3600 audience: iamA continuación, pulse Cargar para crear los recursos para la aplicación. Incluye un nuevo espacio de nombres de Kubernetes tptest, un despliegue y un servicio con un pod.
Puede encontrar el código fuente para la configuración de YAML anterior en GitHub.
-
En la columna de navegación de la izquierda, pulse Despliegues para comprobar el estado del nuevo despliegue trustedprofile-test-deployment. A continuación, pulse Pods en la misma columna de navegación y observe un pod con un nombre que empiece por trustedprofile-test-deployment. Una vez que esté mostrando el estado verde, pase a la siguiente sección.
Probar el perfil de confianza
Con el perfil de confianza y el clúster de Kubernetes con la app en ejecución en su lugar, es el momento de realizar la prueba. Comienza abriendo un intérprete de comandos basado en navegador para ejecutar comandos, una pestaña para los registros del contenedor y otra para los registros de IBM Cloud Logs.
-
En el separador activo actualmente Panel de control deKubernetes con los pods, pulse en el menú con tres puntos a la derecha y pulse con el botón derecho del ratón en Exec en dicho menú. Elija abrir el enlace en una nueva pestaña (shell de contenedor). Abre un shell para el contenedor en ejecución. Todavía en la pestaña del navegador Panel de control deKubernetes, pulse de nuevo en el menú de tres puntos y, a continuación, pulse con el botón izquierdo del ratón en Registros. En el nuevo menú de tres puntos, habilite Renovación automática.
Por último, abra una pestaña con el servicioIBM Cloud Logs y seleccione la pestaña Cloud Logs y haga clic en el nombre de la instancia que está recibiendo los eventos de auditoría.
-
En el separador del navegador shell de contenedor, ejecute el mandato siguiente en el shell para probar la app:
curl -s localhost:8080Lo anterior debería devolver un objeto JSON con codeversion y result. Debería ver alguna actividad de registro nueva en el separador Panel de control deKubernetes con los registros. A continuación, en el separador shell de contenedor, ejecute el mandato siguiente:
curl -s localhost:8080/api/listresources_crn | jqEl mandato invoca la app, intentando recuperar la lista de recursos de la cuenta, pero no se proporciona ningún nombre de perfil de confianza. El resultado debe ser un objeto JSON con formato con un mensaje de error.
-
Repita el mandato anterior, pero ahora especifique qué perfil de confianza utilizar:
curl -s localhost:8080/api/listresources_crn?tpname=TPwithCR | jqAhora, el resultado debe tener formato de objeto JSON con información sobre los recursos de la cuenta. Para la legibilidad, sólo se devuelven los CRN de recurso. Utilice
localhost:8080/api/listresourcespara los detalles completos del objeto. Es posible que también desee intentar un nombre de perfil de confianza diferente y no existente y examinar el mensaje de error.Cuando se invoca, la aplicación lee por primera vez la señal para el recurso de cálculo. A continuación, convierte la señal en una señal de acceso de IAM para el perfil de confianza especificado. Por último, llama a la API de controlador de recursosIBM Cloud para recuperar información sobre las instancias de servicio. El resultado depende de los privilegios configurados del perfil de confianza. Si está interesado, examine el código fuente de la aplicación.
-
Cambia a la pestaña del navegador IBM Cloud Logs y utiliza el cuadro de búsqueda de la parte inferior para buscar el término perfil. Debe ser la instancia configurada como destino de eventos de auditoría. It should return at least one line with
IAM Identity Service: login.computeresource-token TPwithCR.Open the info panelto expand the record to examine details, look for the iniciador section. Lista el perfil de confianza que se ha utilizado para la solicitud e información sobre el recurso de cálculo. El authName debe coincidir con su despliegue desde la pestaña del navegador del panel de controlKubernetes.
Details in the activity log -
Ahora, visite el separador del navegador Panel de control deKubernetes y compruebe el registro del contenedor. La aplicación imprime detalles sobre la señal de acceso JWT que utiliza para autenticarse para listar los recursos. Examine los pares clave/valor individuales, incluido sub (asunto) dos veces. Están relacionados con el perfil de confianza y el recurso de cálculo.
-
Cambie a la pestaña del navegador Perfil de confianza de IAM con la configuración para TPwithCR. En el formulario, pulse el separador Acceso y, a continuación, en el menú de tres puntos para Todos los servicios habilitados para identidad y acceso, seleccione Editar. Ahora, debe mostrar Editar política para TPwithCR. Pulse Editar para Recursos y seleccione Recursos específicos. Seleccione Región como Tipo de atributo y como Valor, por ejemplo, Frankfurt. Finalice pulsando Guardar.
-
Vuelva a la pestaña del navegador shell de contenedor y vuelva a ejecutar este mandato para listar los recursos:
curl -s localhost:8080/api/listresources?tpname=TPwithCR | jqEl resultado puede ser diferente del anterior, en función de dónde haya desplegado otros recursos en su cuenta. Revise los registrosIBM Cloud Logs y las pestañas del navegador del panel de controlKubernetes en busca de nueva actividad de registro.
-
Es posible que desee volver al paso 6 y volver a editar la política de acceso y, a continuación, volver a realizar la prueba con el paso 7. Algunas ideas para editar la política de acceso serían añadir regiones o restringir a servicios específicos en lugar de Todos los servicios habilitados para identidad y acceso.
Eliminación de recursos
Cuando haya terminado de probar el escenario anterior con perfiles de confianza y recursos de cálculo, puede eliminar los recursos siguiendo estos pasos:
- Para suprimir el clúster de Kubernetes, pulse Acciones en la parte superior derecha de la pestaña del navegador Visión general del clústery, a continuación, Suprimir clúster.
- En la pestaña Perfiles de confianza IAM con el perfil de confianza TPwithCR, haz clic en Acciones y Eliminar para eliminar el perfil de confianza.
En función del recurso, es posible que no se suprima de inmediato sino que se retenga (durante 7 días de forma predeterminada). Puede reclamar el recurso suprimiéndolo de forma permanente o lo puede restaurar dentro del periodo de retención. Consulte este documento sobre cómo utilizar una reclamación de recurso.