Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Estrategia de cuentas múltiples

AWS recomienda utilizar una estrategia de cuentas múltiples y organizaciones de AWS para ayudar a aislar y administrar las aplicaciones y los datos empresariales. El uso de una estrategia de cuentas múltiples tiene muchas ventajas:

En las siguientes secciones se explica cómo implementar una estrategia de cuentas múltiples para sus cargas de trabajo de EKS mediante un enfoque de clúster de EKS centralizado o descentralizado.

Planeación de una estrategia de cuentas con múltiples cargas de trabajo para clústeres con varios inquilinos

En una estrategia de AWS con varias cuentas, los recursos que pertenecen a una carga de trabajo determinada, como los buckets de S3, ElastiCache los clústeres y las tablas de DynamoDB, se crean todos en una cuenta de AWS que contiene todos los recursos de esa carga de trabajo. Se denominan cuentas de carga de trabajo y el clúster EKS se implementa en una cuenta denominada cuenta de clúster. Las cuentas de clúster se analizarán en la siguiente sección. La implementación de recursos en una cuenta de carga de trabajo dedicada es similar a la implementación de recursos de Kubernetes en un espacio de nombres dedicado.

Luego, las cuentas de carga de trabajo se pueden desglosar aún más por ciclo de vida de desarrollo de software u otros requisitos, si corresponde. Por ejemplo, una carga de trabajo determinada puede tener una cuenta de producción, una cuenta de desarrollo o cuentas para alojar instancias de esa carga de trabajo en una región específica. Encontrará más información en este documento técnico de AWS.

Puede adoptar los siguientes enfoques al implementar la estrategia de cuentas múltiples de EKS:

Clúster EKS centralizado

En este enfoque, su clúster de EKS se implementará en una única cuenta de AWS llamadaCluster Account. Al utilizar las funciones de IAM para las cuentas de servicio (IRSA) o las identidades de los pods de EKS para ofrecer credenciales de AWS temporales y AWS Resource Access Manager (RAM) para simplificar el acceso a la red, puede adoptar una estrategia de cuentas múltiples para su clúster de EKS con varios inquilinos. La cuenta de clúster contendrá la VPC, las subredes, el clúster de EKS, los recursos de EC2/Fargate cómputo (nodos de trabajo) y cualquier configuración de red adicional necesaria para ejecutar el clúster de EKS.

En una estrategia de cuentas con varias cargas de trabajo para un clúster con varios inquilinos, las cuentas de AWS suelen alinearse con los espacios de nombres de Kubernetes como mecanismo para aislar grupos de recursos. A la hora de implementar una estrategia de cuentas múltiples para clústeres de EKS múltiples, deben seguirse las mejores prácticas de aislamiento de inquilinos dentro de un clúster de EKS de múltiples inquilinos.

Es posible tener varios Cluster Accounts en su organización de AWS, y se recomienda tener varios Cluster Accounts que se ajusten a las necesidades del ciclo de vida del desarrollo de software. En el caso de las cargas de trabajo que funcionan a gran escala, es posible que necesite varias Cluster Accounts para garantizar que haya suficientes cuotas de servicios de Kubernetes y AWS disponibles para todas sus cargas de trabajo.

|En el diagrama anterior, la RAM de AWS se utiliza para compartir subredes de una cuenta de clúster en una cuenta de carga de trabajo. Luego, las cargas de trabajo que se ejecutan en los pods de EKS utilizan las identidades de los pods de IRSA o EKS y el encadenamiento de roles para asumir un rol en su cuenta de carga de trabajo y acceder a sus recursos de AWS.

Implementación de una estrategia de cuentas de múltiples cargas de trabajo para un clúster con varios inquilinos

Uso compartido de subredes con AWS Resource Access Manager

AWS Resource Access Manager (RAM) le permite compartir recursos entre cuentas de AWS.

Si la RAM está habilitada para su organización de AWS, puede compartir las subredes de VPC de la cuenta del clúster con sus cuentas de carga de trabajo. Esto permitirá que los recursos de AWS que pertenecen a sus cuentas de carga de trabajo, como Amazon ElastiCache Clusters o las bases de datos Amazon Relational Database Service (RDS), se desplieguen en la misma VPC que su clúster de EKS y puedan consumirlos las cargas de trabajo que se ejecutan en su clúster de EKS.

Para compartir un recurso a través de la RAM, abra la RAM en la consola de AWS de la cuenta del clúster y seleccione «Recursos compartidos» y «Crear recurso compartido». Asigne un nombre a su recurso compartido y seleccione las subredes que desee compartir. Vuelva a seleccionar Siguiente e introduzca los ID de cuenta de 12 dígitos de las cuentas de carga de trabajo con las que desee compartir las subredes, vuelva a seleccionar Siguiente y, para finalizar, haga clic en Crear recurso compartido. Tras este paso, la cuenta de carga de trabajo puede implementar recursos en esas subredes.

Los recursos compartidos de RAM también se pueden crear mediante programación o con la infraestructura como código.

Elegir entre EKS Pod Identities e IRSA

En re:Invent 2023, AWS lanzó EKS Pod Identities como una forma más sencilla de entregar credenciales de AWS temporales a sus pods en EKS. Tanto las identidades de los pods de IRSA como las de EKS son métodos válidos para entregar credenciales de AWS temporales a los pods de EKS y seguirán siendo compatibles. Debe considerar qué método de entrega se adapta mejor a sus necesidades.

Al trabajar con un clúster de EKS y varias cuentas de AWS, IRSA puede asumir funciones directamente en las cuentas de AWS distintas de la cuenta en la que está alojado directamente el clúster de EKS, mientras que las identidades de los pods de EKS requieren que configure el encadenamiento de roles. Consulte la documentación de EKS para obtener una comparación detallada.

Acceso a los recursos de API de AWS con funciones de IAM para cuentas de servicio

Las funciones de IAM para cuentas de servicio (IRSA) le permiten entregar credenciales de AWS temporales a sus cargas de trabajo que se ejecutan en EKS. El IRSA se puede utilizar para obtener credenciales temporales para las funciones de IAM en las cuentas de carga de trabajo desde la cuenta del clúster. Esto permite que las cargas de trabajo que se ejecutan en los clústeres de EKS de la cuenta del clúster consuman sin problemas los recursos de la API de AWS, como los buckets de S3 alojados en la cuenta de carga de trabajo, y utilicen la autenticación de IAM para recursos como Amazon RDS Databases o Amazon EFS. FileSystems

Solo se puede acceder a los recursos de la API de AWS y a otros recursos que utilizan la autenticación de IAM en una cuenta de carga de trabajo mediante las credenciales de las funciones de IAM en esa misma cuenta de carga de trabajo, excepto cuando el acceso entre cuentas es posible y se ha habilitado de forma explícita.

Habilitar IRSA para el acceso entre cuentas

Para permitir que el IRSA para las cargas de trabajo de su cuenta de clúster acceda a los recursos de sus cuentas de carga de trabajo, primero debe crear un proveedor de identidades OIDC de IAM en su cuenta de carga de trabajo. Esto se puede hacer con el mismo procedimiento que para configurar el IRSA, con la salvedad de que el proveedor de identidad se creará en la cuenta de carga de trabajo.

A continuación, al configurar IRSA para sus cargas de trabajo en EKS, puede seguir los mismos pasos que en la documentación, pero utilizar el identificador de cuenta de 12 dígitos de la cuenta de carga de trabajo, tal y como se indica en la sección «Ejemplo de creación de un proveedor de identidades a partir del clúster de otra cuenta».

Una vez configurado, la aplicación que se ejecute en EKS podrá usar directamente su cuenta de servicio para asumir una función en la cuenta de carga de trabajo y utilizar los recursos que contiene.

Acceso a los recursos de la API de AWS con las identidades de los pods de EKS

Las identidades de los pods de EKS proporcionan otra forma de entregar credenciales de AWS temporales a las cargas de trabajo que se ejecutan en EKS. Las identidades de los pods de EKS se integran con el plano de control de EKS y con un agente del clúster para que los pods reciban las credenciales sin necesidad de crear o administrar un proveedor de identidades OIDC para IAM. Las identidades de pod de EKS son el enfoque recomendado para las nuevas cargas de trabajo en los tipos de nodos compatibles, mientras que las IRSA siguen siendo una alternativa totalmente compatible.

Con EKS Pod Identities, asocias una cuenta de servicio de Kubernetes en tu clúster con un rol de IAM en la misma cuenta de AWS que el clúster. EKS utiliza esta asociación para obtener credenciales temporales para esa función de IAM y entregarlas de forma segura a los pods que utilizan la cuenta de servicio. De este modo, su aplicación podrá utilizar los SDK de AWS estándar y la cadena de credenciales predeterminada para llamar a las API de AWS; no se requieren proveedores de credenciales personalizados ni archivos de configuración.

Habilitar las identidades de los pods de EKS para el acceso entre cuentas

Las identidades de los pods de EKS admiten de forma nativa el acceso entre cuentas mediante el uso de una función de IAM de destino en la cuenta de carga de trabajo y el encadenamiento de funciones de IAM. Al crear una asociación de identidad de pod para una cuenta de servicio de Kubernetes, se especifican tanto una función de IAM de pod en la cuenta del clúster como una función de IAM de destino en la cuenta de carga de trabajo. EKS Pod Identity usa el rol de pod para asumir el rol de destino y devuelve las credenciales temporales del rol de destino al pod.

Consulte este blog de AWS para obtener un recorrido detallado y consideraciones sobre este enfoque.

Identidades de ABAC y EKS Pod para el acceso entre cuentas

Al utilizar EKS Pod Identities para asumir funciones (encadenamiento de funciones) en otras cuentas como parte de una estrategia de cuentas múltiples, tiene la opción de asignar una función de IAM única a cada cuenta de servicio que necesite acceder a otra cuenta, o utilizar una función de IAM común en varias cuentas de servicio y usar ABAC para controlar a qué cuentas puede acceder.

Para usar ABAC para controlar qué cuentas de servicio pueden asumir un rol en otra cuenta con el encadenamiento de roles, debe crear una declaración de política de confianza de roles que solo permita que el rol de IAM del pod asuma un rol desde la cuenta del clúster de EKS (ID de cuenta 111122223333) cuando estén presentes los valores esperados. La siguiente política de confianza de roles solo permitirá que el rol de IAM del pod de la cuenta del clúster de EKS asuma un rol si todas las kubernetes-namespace etiquetas eks-cluster-arn y etiquetas tienen el kubernetes-service-account valor esperado.

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:role/account-a-role"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/kubernetes-service-account": "PayrollApplication",
                    "aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/ProductionCluster",
                    "aws:RequestTag/kubernetes-namespace": "PayrollNamespace"
                }
            }
        }
    ]
}

También puedes usar las políticas de sesión de EKS Pod Identity para reducir aún más los permisos de un pod sin crear funciones de IAM adicionales. Las políticas de sesión se aplican cuando EKS Pod Identity asume el rol y los permisos resultantes son la intersección de la política de rol y la política de sesión; para ver consideraciones y pasos detallados, consulte el blog de AWS Containers Políticas de sesión para Amazon EKS Pod Identity.

Al utilizar esta estrategia, se recomienda garantizar que el rol común de IAM solo tenga sts:TagSession permisos sts:AssumeRole y ningún otro acceso de AWS.

Al utilizar ABAC, es importante controlar quién puede etiquetar las funciones de IAM, los usuarios y las sesiones de STS solo para aquellos que lo necesiten estrictamente. Una persona con la capacidad de establecer kubernetes- o etiquetar podría establecer eks- etiquetas idénticas a las que se transferirían durante el encadenamiento de roles de EKS Pod Identity y, por lo tanto, aumentar sus privilegios. Puede restringir quién tiene acceso para establecer estas etiquetas mediante la política de IAM o la Política de control de servicios (SCP); para ver, por ejemplo, los controles, consulte y. ProtectPodIdentitiesTagsOnRolesAndUsersSTS-Protect-EKS-pod-identities-tags

Elegir entre EKS Pod Identities e IRSA

Tanto las identidades de IRSA como las de EKS Pod son opciones válidas para entregar credenciales de AWS temporales a sus cargas de trabajo de EKS. Las identidades de pod de EKS se recomiendan para las aplicaciones nuevas que se ejecuten en los tipos de nodos compatibles, y las IRSA son una buena opción si ya se cuenta con OIDC e IRSA o se ejecutan en plataformas que no son compatibles con las identidades de pod de EKS.

Tenga en cuenta lo siguiente cuando tenga que tomar una decisión sobre el uso:

Tanto IRSA como EKS Pod Identities admiten estrategias de cuentas múltiples. Puede utilizar ambos enfoques de forma coherente en todo el clúster o adoptar un modelo mixto en el que las cargas de trabajo antiguas sigan utilizando IRSA y las nuevas, utilizando EKS Pod Identities.

De-centralized Clústeres EKS

Con este enfoque, los clústeres de EKS se implementan en las cuentas de AWS de carga de trabajo respectivas y conviven con otros recursos de AWS, como depósitos de Amazon S3, VPC, tablas de Amazon DynamoDB, etc. Cada cuenta de carga de trabajo es independiente, autosuficiente y está gestionada por los respectivos equipos empresariales. Unit/Application Este modelo permite crear planos reutilizables para diversas capacidades de clúster (clúster, procesamiento por lotesAI/ML , uso general, etc.) y vender los clústeres en función de los requisitos del equipo de aplicación. Tanto los equipos de aplicaciones como los de plataformas operan desde sus GitOpsrepositorios respectivos para gestionar las implementaciones en los clústeres de carga de trabajo.

En el diagrama anterior, los clústeres de Amazon EKS y otros recursos de AWS se implementan en las cuentas de carga de trabajo respectivas. Luego, las cargas de trabajo que se ejecutan en los pods de EKS utilizan las identidades de los pods de IRSA o EKS para acceder a sus recursos de AWS.

GitOps es una forma de gestionar el despliegue de aplicaciones e infraestructuras de forma que todo el sistema se describa de forma declarativa en un repositorio de Git. Se trata de un modelo operativo que permite gestionar el estado de varios clústeres de Kubernetes mediante las mejores prácticas de control de versiones, artefactos inmutables y automatización. En este modelo de varios clústeres, cada clúster de carga de trabajo se inicia con varios repositorios de Git, lo que permite a cada equipo (aplicación, plataforma, seguridad, etc.) implementar sus cambios respectivos en el clúster.

Debería utilizar las funciones de IAM para las cuentas de servicio (IRSA) o las identidades de los pods de EKS en cada cuenta para permitir que sus cargas de trabajo de EKS obtengan credenciales de AWS temporales para acceder de forma segura a otros recursos de AWS. Las funciones de IAM se crean en las respectivas cuentas de AWS de carga de trabajo y se asignan a las cuentas de servicio de k8s para proporcionar acceso temporal a IAM. Por lo tanto, en este enfoque no se requiere el acceso entre cuentas. Siga la documentación sobre las funciones de IAM para las cuentas de servicio sobre cómo configurar cada carga de trabajo para IRSA y la documentación sobre las identidades de los pods de EKS sobre cómo configurar las identidades de los pods de EKS en cada cuenta.

Redes centralizadas

También puede utilizar la RAM de AWS para compartir las subredes de la VPC con las cuentas de carga de trabajo y lanzar clústeres de Amazon EKS y otros recursos de AWS en ellas. Esto permite una red centralizada managment/administration, una conectividad de red simplificada y clústeres EKS descentralizados. Consulte este blog de AWS para obtener un recorrido detallado y consideraciones sobre este enfoque.

En el diagrama anterior, la RAM de AWS se utiliza para compartir subredes de una cuenta de red central en una cuenta de carga de trabajo. Luego, el clúster EKS y otros recursos de AWS se lanzan en esas subredes en las cuentas de carga de trabajo respectivas. Los pods de EKS utilizan las identidades de los pods de IRSA o EKS para acceder a sus recursos de AWS.

Centralizados frente a clústeres de De-centralized EKS

La decisión de utilizar uno centralizado o De-centralized dependerá de sus requisitos. En esta tabla se muestran las principales diferencias con cada estrategia.