mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 14:40:37 -08:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -22,7 +22,7 @@ Par conséquent, il y a **deux types de comptes dans une organisation** (nous pa
|
||||
- Gérer les invitations
|
||||
- Appliquer des politiques aux entités (roots, OUs ou comptes) au sein de l'organisation
|
||||
- Activer l'intégration avec les services AWS pris en charge pour fournir des fonctionnalités de service à tous les comptes de l'organisation.
|
||||
- Il est possible de se connecter en tant qu'utilisateur root en utilisant l'email et le mot de passe utilisés pour créer ce compte root/organisation.
|
||||
- Il est possible de se connecter en tant qu'utilisateur root en utilisant l'email et le mot de passe utilisés pour créer ce compte/organisation root.
|
||||
|
||||
Le compte de gestion a les **responsabilités d'un compte payeur** et est responsable du paiement de tous les frais accumulés par les comptes membres. Vous ne pouvez pas changer le compte de gestion d'une organisation.
|
||||
|
||||
@@ -43,7 +43,7 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
|
||||
Une **service control policy (SCP)** est une politique qui spécifie les services et actions que les utilisateurs et rôles peuvent utiliser dans les comptes que la SCP affecte. Les SCP sont **similaires aux politiques de permissions IAM** sauf qu'elles **ne donnent aucune permission**. Au lieu de cela, les SCP spécifient les **permissions maximales** pour une organisation, une unité organisationnelle (OU) ou un compte. Lorsque vous attachez une SCP à la racine de votre organisation ou à une OU, la **SCP limite les permissions pour les entités dans les comptes membres**.
|
||||
|
||||
C'est le SEUL moyen par lequel **même l'utilisateur root peut être arrêté** de faire quelque chose. Par exemple, cela pourrait être utilisé pour empêcher les utilisateurs de désactiver CloudTrail ou de supprimer des sauvegardes.\
|
||||
Le seul moyen de contourner cela est de compromettre également le **compte principal** qui configure les SCP (le compte principal ne peut pas être bloqué).
|
||||
Le seul moyen de contourner cela est de compromettre également le **compte maître** qui configure les SCP (le compte maître ne peut pas être bloqué).
|
||||
|
||||
> [!WARNING]
|
||||
> Notez que **les SCP ne restreignent que les principaux dans le compte**, donc d'autres comptes ne sont pas affectés. Cela signifie qu'avoir une SCP qui refuse `s3:GetObject` n'arrêtera pas les gens d'**accéder à un bucket S3 public** dans votre compte.
|
||||
@@ -53,10 +53,14 @@ Exemples de SCP :
|
||||
- Refuser complètement le compte root
|
||||
- Autoriser uniquement des régions spécifiques
|
||||
- Autoriser uniquement des services sur liste blanche
|
||||
- Refuser que GuardDuty, CloudTrail et S3 Public Block Access soient désactivés
|
||||
- Refuser que les rôles de sécurité/réponse aux incidents soient supprimés ou modifiés.
|
||||
- Refuser que les sauvegardes soient supprimées.
|
||||
- Refuser de créer des utilisateurs IAM et des clés d'accès
|
||||
- Refuser l'accès à GuardDuty, CloudTrail et S3 Public Block Access de
|
||||
|
||||
être désactivé
|
||||
|
||||
- Refuser la suppression ou la modification des rôles de sécurité/réponse aux incidents.
|
||||
|
||||
- Refuser la suppression des sauvegardes.
|
||||
- Refuser la création d'utilisateurs IAM et de clés d'accès
|
||||
|
||||
Trouvez des **exemples JSON** dans [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
|
||||
|
||||
@@ -111,7 +115,7 @@ Chaque fois que vous devez **changer la clé d'accès**, voici le processus que
|
||||
### MFA - Authentification Multi-Facteurs
|
||||
|
||||
Il est utilisé pour **créer un facteur supplémentaire pour l'authentification** en plus de vos méthodes existantes, telles que le mot de passe, créant ainsi un niveau d'authentification multi-facteurs.\
|
||||
Vous pouvez utiliser une **application virtuelle gratuite ou un appareil physique**. Vous pouvez utiliser des applications comme Google Authenticator gratuitement pour activer un MFA dans AWS.
|
||||
Vous pouvez utiliser une **application virtuelle gratuite ou un dispositif physique**. Vous pouvez utiliser des applications comme Google Authenticator gratuitement pour activer un MFA dans AWS.
|
||||
|
||||
Les politiques avec des conditions MFA peuvent être attachées aux éléments suivants :
|
||||
|
||||
@@ -124,7 +128,7 @@ Notez que **les informations d'identification `AssumeRole` ne contiennent pas ce
|
||||
```bash
|
||||
aws sts get-session-token --serial-number <arn_device> --token-code <code>
|
||||
```
|
||||
As [**indiqué ici**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), il existe de nombreux cas où **MFA ne peut pas être utilisé**.
|
||||
Comme [**indiqué ici**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), il existe de nombreux cas où **MFA ne peut pas être utilisé**.
|
||||
|
||||
### [Groupes d'utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
|
||||
@@ -137,21 +141,21 @@ Voici quelques caractéristiques importantes des groupes d'utilisateurs :
|
||||
- Un **groupe d'utilisateurs** peut **contenir plusieurs utilisateurs**, et un **utilisateur** peut **appartenir à plusieurs groupes**.
|
||||
- **Les groupes d'utilisateurs ne peuvent pas être imbriqués** ; ils ne peuvent contenir que des utilisateurs, pas d'autres groupes d'utilisateurs.
|
||||
- Il n'y a **pas de groupe d'utilisateurs par défaut qui inclut automatiquement tous les utilisateurs du compte AWS**. Si vous souhaitez avoir un groupe d'utilisateurs comme ça, vous devez le créer et assigner chaque nouvel utilisateur à celui-ci.
|
||||
- Le nombre et la taille des ressources IAM dans un compte AWS, comme le nombre de groupes, et le nombre de groupes dont un utilisateur peut être membre, sont limités. Pour plus d'informations, voir [Quotas IAM et AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
|
||||
- Le nombre et la taille des ressources IAM dans un compte AWS, comme le nombre de groupes et le nombre de groupes dont un utilisateur peut être membre, sont limités. Pour plus d'informations, voir [Quotas IAM et AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
|
||||
|
||||
### [Rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
|
||||
Un **rôle IAM** est très **similaire** à un **utilisateur**, en ce sens qu'il s'agit d'une **identité avec des politiques d'autorisation qui déterminent ce qu'elle** peut et ne peut pas faire dans AWS. Cependant, un rôle **n'a pas de credentials** (mot de passe ou clés d'accès) qui lui sont associés. Au lieu d'être associé de manière unique à une personne, un rôle est destiné à être **assumé par quiconque en a besoin (et a suffisamment de permissions)**. Un **utilisateur IAM peut assumer un rôle pour temporairement** prendre des autorisations différentes pour une tâche spécifique. Un rôle peut être **assigné à un** [**utilisateur fédéré**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) qui se connecte en utilisant un fournisseur d'identité externe au lieu d'IAM.
|
||||
Un **rôle IAM** est très **similaire** à un **utilisateur**, en ce sens qu'il s'agit d'une **identité avec des politiques d'autorisation qui déterminent ce qu'il peut et ne peut pas faire dans AWS**. Cependant, un rôle **n'a pas de credentials** (mot de passe ou clés d'accès) qui lui sont associés. Au lieu d'être associé de manière unique à une personne, un rôle est destiné à être **assumé par quiconque en a besoin (et a suffisamment de permissions)**. Un **utilisateur IAM peut assumer un rôle pour temporairement** prendre des autorisations différentes pour une tâche spécifique. Un rôle peut être **assigné à un** [**utilisateur fédéré**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) qui se connecte en utilisant un fournisseur d'identité externe au lieu d'IAM.
|
||||
|
||||
Un rôle IAM se compose de **deux types de politiques** : Une **politique de confiance**, qui ne peut pas être vide, définissant **qui peut assumer** le rôle, et une **politique d'autorisation**, qui ne peut pas être vide, définissant **ce qu'il peut accéder**.
|
||||
|
||||
#### Service de jetons de sécurité AWS (STS)
|
||||
|
||||
Le Service de jetons de sécurité AWS (STS) est un service web qui facilite **l'émission de credentials temporaires à privilèges limités**. Il est spécifiquement conçu pour :
|
||||
Le service de jetons de sécurité AWS (STS) est un service web qui facilite **l'émission de credentials temporaires à privilèges limités**. Il est spécifiquement conçu pour :
|
||||
|
||||
### [Credentials temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
|
||||
**Les credentials temporaires sont principalement utilisés avec les rôles IAM**, mais il existe également d'autres utilisations. Vous pouvez demander des credentials temporaires qui ont un ensemble de permissions plus restreint que votre utilisateur IAM standard. Cela **empêche** que vous **effectuiez accidentellement des tâches qui ne sont pas autorisées** par les credentials plus restreints. Un avantage des credentials temporaires est qu'ils expirent automatiquement après une période déterminée. Vous avez le contrôle sur la durée pendant laquelle les credentials sont valides.
|
||||
Les **credentials temporaires sont principalement utilisés avec les rôles IAM**, mais il existe également d'autres utilisations. Vous pouvez demander des credentials temporaires qui ont un ensemble de permissions plus restreint que votre utilisateur IAM standard. Cela **empêche** que vous **effectuiez accidentellement des tâches qui ne sont pas autorisées** par les credentials plus restreints. Un avantage des credentials temporaires est qu'ils expirent automatiquement après une période déterminée. Vous avez le contrôle sur la durée pendant laquelle les credentials sont valides.
|
||||
|
||||
### Politiques
|
||||
|
||||
@@ -163,7 +167,7 @@ Sont utilisées pour attribuer des permissions. Il existe 2 types :
|
||||
- Politiques gérées par le client : Configurées par vous. Vous pouvez créer des politiques basées sur des politiques gérées par AWS (en modifiant l'une d'elles et en créant la vôtre), en utilisant le générateur de politiques (une vue GUI qui vous aide à accorder et refuser des permissions) ou en écrivant la vôtre.
|
||||
|
||||
Par **défaut, l'accès** est **refusé**, l'accès sera accordé si un rôle explicite a été spécifié.\
|
||||
Si **un seul "Refuser" existe, il remplacera le "Autoriser"**, sauf pour les demandes qui utilisent les credentials de sécurité root du compte AWS (qui sont autorisées par défaut).
|
||||
Si **un "Deny" unique existe, il remplacera le "Allow"**, sauf pour les demandes qui utilisent les credentials de sécurité root du compte AWS (qui sont autorisées par défaut).
|
||||
```javascript
|
||||
{
|
||||
"Version": "2012-10-17", //Version of the policy
|
||||
@@ -189,26 +193,26 @@ Si **un seul "Refuser" existe, il remplacera le "Autoriser"**, sauf pour les dem
|
||||
Les [champs globaux qui peuvent être utilisés pour des conditions dans n'importe quel service sont documentés ici](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
|
||||
Les [champs spécifiques qui peuvent être utilisés pour des conditions par service sont documentés ici](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
|
||||
|
||||
#### Politiques en ligne
|
||||
#### Politiques Inline
|
||||
|
||||
Ce type de politiques est **directement attribué** à un utilisateur, un groupe ou un rôle. Ainsi, elles n'apparaissent pas dans la liste des politiques car d'autres peuvent les utiliser.\
|
||||
Les politiques en ligne sont utiles si vous souhaitez **maintenir une relation stricte un à un entre une politique et l'identité** à laquelle elle est appliquée. Par exemple, vous voulez vous assurer que les autorisations dans une politique ne sont pas attribuées par inadvertance à une identité autre que celle pour laquelle elles sont destinées. Lorsque vous utilisez une politique en ligne, les autorisations dans la politique ne peuvent pas être attachées par inadvertance à la mauvaise identité. De plus, lorsque vous utilisez la console de gestion AWS pour supprimer cette identité, les politiques intégrées à l'identité sont également supprimées. C'est parce qu'elles font partie de l'entité principale.
|
||||
Ce type de politiques est **directement attribué** à un utilisateur, un groupe ou un rôle. Ainsi, elles n'apparaissent pas dans la liste des Politiques car d'autres peuvent les utiliser.\
|
||||
Les politiques inline sont utiles si vous souhaitez **maintenir une relation stricte un à un entre une politique et l'identité** à laquelle elle est appliquée. Par exemple, vous voulez vous assurer que les autorisations dans une politique ne sont pas attribuées par inadvertance à une identité autre que celle pour laquelle elles sont destinées. Lorsque vous utilisez une politique inline, les autorisations dans la politique ne peuvent pas être attachées par inadvertance à la mauvaise identité. De plus, lorsque vous utilisez la console de gestion AWS pour supprimer cette identité, les politiques intégrées dans l'identité sont également supprimées. C'est parce qu'elles font partie de l'entité principale.
|
||||
|
||||
#### Politiques de seau de ressources
|
||||
#### Politiques de Bucket de Ressources
|
||||
|
||||
Ce sont des **politiques** qui peuvent être définies dans des **ressources**. **Toutes les ressources d'AWS ne les prennent pas en charge**.
|
||||
|
||||
Si un principal n'a pas de refus explicite à leur égard, et qu'une politique de ressource leur accorde l'accès, alors ils sont autorisés.
|
||||
Si un principal n'a pas de refus explicite à leur sujet, et qu'une politique de ressource leur accorde l'accès, alors ils sont autorisés.
|
||||
|
||||
### Limites IAM
|
||||
|
||||
Les limites IAM peuvent être utilisées pour **limiter les autorisations auxquelles un utilisateur ou un rôle devrait avoir accès**. De cette façon, même si un ensemble différent d'autorisations est accordé à l'utilisateur par une **politique différente**, l'opération **échouera** s'il essaie de les utiliser.
|
||||
|
||||
Une limite est simplement une politique attachée à un utilisateur qui **indique le niveau maximum d'autorisations que l'utilisateur ou le rôle peut avoir**. Donc, **même si l'utilisateur a un accès Administrateur**, si la limite indique qu'il ne peut lire que des seaux S·, c'est le maximum qu'il peut faire.
|
||||
Une limite est simplement une politique attachée à un utilisateur qui **indique le niveau maximum d'autorisations que l'utilisateur ou le rôle peut avoir**. Donc, **même si l'utilisateur a un accès Administrateur**, si la limite indique qu'il ne peut lire que des buckets S·, c'est le maximum qu'il peut faire.
|
||||
|
||||
**Cela**, **les SCP** et **le respect du principe du moindre privilège** sont les moyens de contrôler que les utilisateurs n'ont pas plus d'autorisations que celles dont ils ont besoin.
|
||||
|
||||
### Politiques de session
|
||||
### Politiques de Session
|
||||
|
||||
Une politique de session est une **politique définie lorsqu'un rôle est assumé** d'une manière ou d'une autre. Cela sera comme une **limite IAM pour cette session** : Cela signifie que la politique de session ne donne pas d'autorisations mais **les restreint à celles indiquées dans la politique** (les autorisations maximales étant celles que le rôle a).
|
||||
|
||||
@@ -220,14 +224,14 @@ aws sts assume-role \
|
||||
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
|
||||
[--policy <file://policy.json>]
|
||||
```
|
||||
Notez qu'en défaut, **AWS peut ajouter des politiques de session aux sessions** qui vont être générées pour d'autres raisons. Par exemple, dans [les rôles supposés cognito non authentifiés](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) par défaut (en utilisant une authentification améliorée), AWS générera **des identifiants de session avec une politique de session** qui limite les services auxquels la session peut accéder [**à la liste suivante**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
|
||||
Notez qu'en défaut, **AWS peut ajouter des politiques de session aux sessions** qui vont être générées pour d'autres raisons. Par exemple, dans [les rôles supposés cognito non authentifiés](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) par défaut (en utilisant l'authentification améliorée), AWS générera **des identifiants de session avec une politique de session** qui limite les services auxquels la session peut accéder [**à la liste suivante**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
|
||||
|
||||
Par conséquent, si à un moment donné vous rencontrez l'erreur "... parce qu'aucune politique de session ne permet le ...", et que le rôle a accès pour effectuer l'action, c'est parce que **il y a une politique de session qui l'empêche**.
|
||||
|
||||
### Fédération d'identité
|
||||
|
||||
La fédération d'identité **permet aux utilisateurs des fournisseurs d'identité qui sont externes** à AWS d'accéder aux ressources AWS de manière sécurisée sans avoir à fournir les identifiants d'utilisateur AWS d'un compte IAM valide.\
|
||||
Un exemple de fournisseur d'identité peut être votre propre **Microsoft Active Directory** (via **SAML**) ou des services **OpenID** (comme **Google**). L'accès fédéré permettra alors aux utilisateurs de l'intérieur d'accéder à AWS.
|
||||
Un exemple de fournisseur d'identité peut être votre propre **Microsoft Active Directory** d'entreprise (via **SAML**) ou des services **OpenID** (comme **Google**). L'accès fédéré permettra alors aux utilisateurs de l'intérieur d'accéder à AWS.
|
||||
|
||||
Pour configurer cette confiance, un **fournisseur d'identité IAM est généré (SAML ou OAuth)** qui **fera confiance** à la **autre plateforme**. Ensuite, au moins un **rôle IAM est attribué (faisant confiance) au fournisseur d'identité**. Si un utilisateur de la plateforme de confiance accède à AWS, il le fera en accédant au rôle mentionné.
|
||||
|
||||
@@ -243,13 +247,13 @@ Le domaine de connexion sera quelque chose comme `<user_input>.awsapps.com`.
|
||||
|
||||
Pour connecter les utilisateurs, il y a 3 sources d'identité qui peuvent être utilisées :
|
||||
|
||||
- Répertoire du Centre d'identité : Utilisateurs AWS réguliers
|
||||
- Répertoire Identity Center : Utilisateurs AWS réguliers
|
||||
- Active Directory : Prend en charge différents connecteurs
|
||||
- Fournisseur d'identité externe : Tous les utilisateurs et groupes proviennent d'un fournisseur d'identité externe (IdP)
|
||||
|
||||
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Dans le cas le plus simple du répertoire du Centre d'identité, le **Centre d'identité aura une liste d'utilisateurs et de groupes** et pourra **attribuer des politiques** à eux pour **n'importe lequel des comptes** de l'organisation.
|
||||
Dans le cas le plus simple du répertoire Identity Center, le **Centre d'identité aura une liste d'utilisateurs et de groupes** et sera capable d'**attribuer des politiques** à eux pour **n'importe lequel des comptes** de l'organisation.
|
||||
|
||||
Pour donner accès à un utilisateur/groupe du Centre d'identité à un compte, un **fournisseur d'identité SAML faisant confiance au Centre d'identité sera créé**, et un **rôle faisant confiance au fournisseur d'identité avec les politiques indiquées sera créé** dans le compte de destination.
|
||||
|
||||
@@ -261,7 +265,7 @@ Par conséquent, même si vous voyez 2 rôles avec une politique en ligne appel
|
||||
|
||||
### Confiances et rôles inter-comptes
|
||||
|
||||
**Un utilisateur** (faisant confiance) peut créer un rôle inter-comptes avec certaines politiques et ensuite, **permettre à un autre utilisateur** (de confiance) d'**accéder à son compte** mais seulement **avec l'accès indiqué dans les nouvelles politiques de rôle**. Pour créer cela, il suffit de créer un nouveau rôle et de sélectionner le rôle inter-comptes. Les rôles pour l'accès inter-comptes offrent deux options. Fournir un accès entre les comptes AWS que vous possédez, et fournir un accès entre un compte que vous possédez et un compte AWS tiers.\
|
||||
**Un utilisateur** (faisant confiance) peut créer un rôle inter-comptes avec certaines politiques et ensuite, **permettre à un autre utilisateur** (de confiance) d'**accéder à son compte** mais seulement **en ayant l'accès indiqué dans les nouvelles politiques de rôle**. Pour créer cela, il suffit de créer un nouveau rôle et de sélectionner le rôle inter-comptes. Les rôles pour l'accès inter-comptes offrent deux options. Fournir un accès entre les comptes AWS que vous possédez, et fournir un accès entre un compte que vous possédez et un compte AWS tiers.\
|
||||
Il est recommandé de **spécifier l'utilisateur qui est de confiance et de ne pas mettre quelque chose de générique** car sinon, d'autres utilisateurs authentifiés comme les utilisateurs fédérés pourront également abuser de cette confiance.
|
||||
|
||||
### AWS Simple AD
|
||||
@@ -282,7 +286,7 @@ L'application utilise AssumeRoleWithWebIdentity pour créer des identifiants tem
|
||||
|
||||
### Autres options IAM
|
||||
|
||||
- Vous pouvez **définir une politique de mot de passe** avec des options comme la longueur minimale et les exigences de mot de passe.
|
||||
- Vous pouvez **définir un paramètre de politique de mot de passe** avec des options comme la longueur minimale et les exigences de mot de passe.
|
||||
- Vous pouvez **télécharger un "Rapport d'identifiants"** avec des informations sur les identifiants actuels (comme le temps de création de l'utilisateur, si le mot de passe est activé...). Vous pouvez générer un rapport d'identifiants aussi souvent qu'une fois toutes les **quatre heures**.
|
||||
|
||||
La gestion des identités et des accès AWS (IAM) fournit un **contrôle d'accès granulaire** sur l'ensemble d'AWS. Avec IAM, vous pouvez spécifier **qui peut accéder à quels services et ressources**, et sous quelles conditions. Avec les politiques IAM, vous gérez les permissions de votre main-d'œuvre et de vos systèmes pour **assurer des permissions de moindre privilège**.
|
||||
@@ -335,7 +339,7 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT
|
||||
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
|
||||
region = eu-west-2
|
||||
```
|
||||
If you need to access **different AWS accounts** and your profile was given access to **assume a role inside those accounts**, you don't need to call manually STS every time (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) and configure the credentials.
|
||||
Si vous devez accéder à **différents comptes AWS** et que votre profil a été autorisé à **assumer un rôle dans ces comptes**, vous n'avez pas besoin d'appeler manuellement STS à chaque fois (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) et de configurer les identifiants.
|
||||
|
||||
Vous pouvez utiliser le fichier `~/.aws/config` pour [**indiquer quels rôles assumer**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), puis utiliser le paramètre `--profile` comme d'habitude (l'`assume-role` sera effectué de manière transparente pour l'utilisateur).\
|
||||
Un exemple de fichier de configuration :
|
||||
|
||||
Reference in New Issue
Block a user