` sustitúyalo por el Cuenta de AWS ID que seleccionó en el paso 2:{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::root"
},
"Action": [
"organizations:ListAccounts",
"organizations:DescribeOrganization",
"organizations:DescribeOrganizationalUnit",
"organizations:ListRoots",
"organizations:ListAWSServiceAccessForOrganization",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
}
]
} | Administrador de la nube |
| Actualice los valores predeterminados del repositorio de ejemplo. | Para configurar el RVM para que funcione en su entorno específico Región de AWS, haga lo siguiente:[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html) | DevOps ingeniero |
### Inicialización de la infraestructura
| Tarea | Descripción | Habilidades requeridas |
| --- | --- | --- |
| Inicie el repositorio de la RVM. | Este paso es necesario para crear los roles de IAM y la política de confianza de OIDC que utiliza la propia canalización de la RVM, de modo que pueda empezar a operar y ofrecer otros roles.
En la cuenta de la RVM, ponga en marcha manualmente un comando `terraform apply` desde el directorio `scripts/bootstrap`. Proporcione los valores necesarios en función de la documentación de las variables. | DevOps ingeniero |
### Configuración de operaciones
| Tarea | Descripción | Habilidades requeridas |
| --- | --- | --- |
| Implemente los roles `github-workflow-rvm` y `github-workflow-rvm-readonly` en todas las cuentas. | Elija un método de implementación que se adapte a las prácticas de su organización, como AFT o StackSets. Utilice ese método para implementar las dos roles de IAM del archivo `scripts/assumed_role/main.tf` (nombres predeterminados `github-workflow-rvm` y `github-workflow-rvm-readonly`) en cada cuenta en la que desee que la RVM pueda crear roles de canalización.
Estos roles de IAM tienen políticas de confianza que permiten que el rol de asunción de roles de la cuenta de la RVM (o su `readonly` equivalente) los asuma. Los roles también tienen políticas de permisos de IAM que les permiten leer roles y escribir (a menos que usen el rol `readonly`) en ellos, siempre que coincidan con `github-workflow-role-*`. | Administrador de AWS |
| Ponga en marcha el flujo de trabajo `generate_providers_and_account_vars`. | Para configurar su RVM de forma que esté lista para crear roles de canalización, haga lo siguiente:[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html)
Una vez finalizado el flujo de trabajo, la RVM está listo para hacer lo siguiente:[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html) | DevOps ingeniero |
## Resolución de problemas
| Problema | Solución |
| --- | --- |
| He creado un rol mediante el RVM, pero GitHub no puedo asumirlo. | Compruebe que el nombre del GitHub repositorio coincide con el nombre proporcionado al `github_workflow_roles` módulo. El alcance de los roles solo permite que un único repositorio pueda asumirlos.
Del mismo modo, compruebe que la rama utilizada en la GitHub canalización coincida con el nombre de la rama proporcionada al `github_workflow_roles` módulo. Por lo general, los roles creados por la RVM con permisos de escritura solo los pueden usar los flujos de trabajo relacionados con la rama `main` (es decir, las implementaciones provenientes de `main`). |
| Mi rol de solo lectura no puede poner en marcha su canalización porque carece de permisos para leer un recurso específico. | Si bien la `ReadOnlyAccess` política proporciona amplios permisos de solo lectura, no incluye algunas acciones de lectura (por ejemplo, determinadas AWS Security Hub CSPM acciones).
Puede agregar permisos de acciones específicas mediante el parámetro `inline_policy_readonly` del módulo `github-workflow-roles`. |
## Recursos relacionados
+ [Prácticas recomendadas de uso AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-bestpractices.html)
+ [Organizar su AWS entorno mediante varias cuentas](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [Descripción general de AWS Control Tower Account Factory para Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)
+ [Mejores prácticas en materia de políticas](https://docs.aws.amazon.com/codepipeline/latest/userguide/security_iam_service-with-iam-policy-best-practices.html)
## Información adicional
**Uso de GitHub entornos**
GitHub Los entornos son un enfoque alternativo a las restricciones basadas en las sucursales para el acceso a los roles. Si prefiere utilizar un GitHub entorno, a continuación se muestra un ejemplo de la sintaxis de una condición adicional de la política de confianza de IAM. Esta sintaxis especifica que el rol solo se puede usar cuando la GitHub acción se ejecuta en el `Production` entorno.
```
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:environment:Production"
}
```
La sintaxis de ejemplo usa los siguientes valores de marcador de posición:
+ `octo-org`es el nombre GitHub de la organización.
+ `octo-repo` es el nombre del repositorio.
+ `Production`es el nombre del GitHub entorno específico.