hacktricks-cloud/src/pentesting-cloud/aws-security/aws-basic-information/README.md

AWS - Basiese Inligting

{{#include ../../../banners/hacktricks-training.md}}

Organisasie Hiërargie

Rekeninge

In AWS is daar 'n root rekening, wat die ouerhouer is vir al die rekening vir jou organisasie. U hoef egter nie daardie rekening te gebruik om hulpbronne te ontplooi nie, u kan ander rekeninge skep om verskillende AWS infrastruktuur van mekaar te skei.

Dit is baie interessant vanuit 'n veiligheid oogpunt, aangesien een rekening nie in staat sal wees om hulpbronne van 'n ander rekening te benader (behalwe as brûe spesifiek geskep word), so op hierdie manier kan u grense tussen ontplooiings skep.

Daarom is daar twee tipes rekeninge in 'n organisasie (ons praat van AWS rekeninge en nie gebruikersrekeninge nie): 'n enkele rekening wat as die bestuurrekening aangewys word, en een of meer lidrekeninge.

• Die bestuurrekening (die root rekening) is die rekening wat u gebruik om die organisasie te skep. Van die organisasie se bestuurrekening kan u die volgende doen:

• Skep rekeninge in die organisasie

• Nooi ander bestaande rekeninge na die organisasie

• Verwyder rekeninge uit die organisasie

• Bestuur uitnodigings

• Pas beleide toe op entiteite (wortels, OU's, of rekeninge) binne die organisasie

• Aktiveer integrasie met ondersteunende AWS dienste om diensfunksionaliteit oor al die rekeninge in die organisasie te bied.

• Dit is moontlik om in te log as die root gebruiker met die e-pos en wagwoord wat gebruik is om hierdie root rekening/organisasie te skep.

Die bestuurrekening het die verantwoordelikhede van 'n betaler rekening en is verantwoordelik vir die betaling van alle koste wat deur die lidrekeninge opgeloop word. U kan nie 'n organisasie se bestuurrekening verander nie.

• Lidrekeninge maak al die res van die rekeninge in 'n organisasie uit. 'n Rekening kan slegs 'n lid van een organisasie op 'n slag wees. U kan 'n beleid aan 'n rekening koppel om kontroles slegs op daardie een rekening toe te pas.
• Lidrekeninge moet 'n geldige e-posadres gebruik en kan 'n naam hê, in die algemeen sal hulle nie in staat wees om die faktuur te bestuur nie (maar hulle mag toegang daartoe gegee word).

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Organisasie-eenhede

Rekeninge kan gegroepeer word in Organisasie-eenhede (OU). Op hierdie manier kan jy beleide vir die Organisasie-eenheid skep wat gaan wees toegepas op al die kindrekening. Let daarop dat 'n OU ander OU's as kinders kan hê.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Service Control Policy (SCP)

'n service control policy (SCP) is 'n beleid wat die dienste en aksies spesifiseer wat gebruikers en rolle in die rekeninge wat die SCP beïnvloed, kan gebruik. SCP's is soortgelyk aan IAM toestemmingsbeleide, behalwe dat hulle nie enige toestemmings toeken nie. In plaas daarvan spesifiseer SCP's die maksimum toestemmings vir 'n organisasie, organisatoriese eenheid (OU), of rekening. Wanneer jy 'n SCP aan jou organisasie wortel of 'n OU heg, beperk die SCP toestemmings vir entiteite in lid rekeninge.

Dit is die ENIGE manier waarop selfs die wortelgebruiker gestop kan word om iets te doen. Byvoorbeeld, dit kan gebruik word om gebruikers te stop om CloudTrail te deaktiveer of rugsteun te verwyder.
Die enigste manier om dit te omseil, is om ook die master account wat die SCP's konfigureer, te kompromitteer (master account kan nie geblokkeer word nie).

Warning

Let daarop dat SCP's slegs die principals in die rekening beperk, so ander rekeninge word nie beïnvloed nie. Dit beteken dat 'n SCP wat s3:GetObject weier, nie mense sal stop om toegang te verkry tot 'n openbare S3-bucket in jou rekening nie.

SCP voorbeelde:

• Weier die wortelrekening heeltemal
• Laat slegs spesifieke streke toe
• Laat slegs witgelysde dienste toe
• Weier GuardDuty, CloudTrail, en S3 Publieke Blok Toegang van

om gedeaktiveer te word

• Weier sekuriteit/voorval respons rolle om verwyder of

gewysig te word.

• Weier rugsteun om verwyder te word.
• Weier die skep van IAM gebruikers en toegang sleutels

Vind JSON voorbeelde in https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

ARN

Amazon Resource Name is die unieke naam wat elke hulpbron binne AWS het, dit is soos volg saamgestel:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

Note dat daar 4 partities in AWS is, maar slegs 3 maniere om hulle te noem:

• AWS Standard: aws
• AWS China: aws-cn
• AWS US publieke Internet (GovCloud): aws-us-gov
• AWS Secret (US Classified): aws

IAM - Identiteit en Toegang Bestuur

IAM is die diens wat jou sal toelaat om Verifikasie, Magtiging en Toegangsbeheer binne jou AWS-rekening te bestuur.

• Verifikasie - Proses om 'n identiteit te definieer en die verifikasie van daardie identiteit. Hierdie proses kan onderverdeel word in: Identifikasie en verifikasie.
• Magtiging - Bepaal wat 'n identiteit kan toegang tot binne 'n stelsel nadat dit geverifieer is.
• Toegangsbeheer - Die metode en proses van hoe toegang tot 'n veilige hulpbron toegestaan word.

IAM kan gedefinieer word deur sy vermoë om verifikasie, magtiging en toegangsbeheer meganismes van identiteite na jou hulpbronne binne jou AWS-rekening te bestuur, te beheer en te regeer.

AWS rekening wortel gebruiker

Wanneer jy vir die eerste keer 'n Amazon Web Services (AWS) rekening skep, begin jy met 'n enkele aanmeld identiteit wat volledige toegang tot alle AWS dienste en hulpbronne in die rekening het. Dit is die AWS rekening wortel gebruiker en word verkry deur in te teken met die e-posadres en wagwoord wat jy gebruik het om die rekening te skep.

Let daarop dat 'n nuwe admin gebruiker minder toestemmings sal hê as die wortel gebruiker.

Vanuit 'n sekuriteits oogpunt, word dit aanbeveel om ander gebruikers te skep en om hierdie een te vermy.

IAM gebruikers

'n IAM gebruiker is 'n entiteit wat jy in AWS skep om die persoon of toepassing wat dit gebruik om met AWS te kommunikeer te verteenwoordig. 'n Gebruiker in AWS bestaan uit 'n naam en geloofsbriewe (wagwoord en tot twee toegang sleutels).

Wanneer jy 'n IAM gebruiker skep, gee jy dit toestemmings deur dit 'n lid van 'n gebruikersgroep te maak wat toepaslike toestemming beleide het (aanbeveel), of deur beleide direk aan die gebruiker te heg.

Gebruikers kan MFA geaktiveer hê om in te teken deur die konsole. API tokens van MFA geaktiveerde gebruikers is nie deur MFA beskerm nie. As jy wil die toegang van 'n gebruiker se API sleutels met MFA beperk, moet jy in die beleid aandui dat om sekere aksies uit te voer, MFA teenwoordig moet wees (voorbeeld hier).

CLI

• Toegang Sleutel ID: 20 ewekansige hoofletters alfanumeriese karakters soos AKHDNAPO86BSHKDIRYT
• Geheime toegang sleutel ID: 40 ewekansige hoë en lae letters: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Dit is nie moontlik om verlore geheime toegang sleutel ID's te herstel nie).

Wanneer jy die Toegang Sleutel moet verander, is dit die proses wat jy moet volg:
&#xNAN;Create 'n nuwe toegang sleutel -> Pas die nuwe sleutel toe op stelsel/toepassing -> merk oorspronklike een as inaktief -> Toets en verifieer dat die nuwe toegang sleutel werk -> Verwyder ou toegang sleutel

MFA - Multi Faktor Verifikasie

Dit word gebruik om 'n addisionele faktor vir verifikasie te skep benewens jou bestaande metodes, soos wagwoord, en skep dus 'n multi-faktor vlak van verifikasie.
Jy kan 'n gratis virtuele toepassing of 'n fisiese toestel gebruik. Jy kan toepassings soos google verifikasie gratis gebruik om 'n MFA in AWS te aktiveer.

Beleide met MFA voorwaardes kan aan die volgende geheg word:

• 'n IAM gebruiker of groep
• 'n hulpbron soos 'n Amazon S3 emmer, Amazon SQS tou, of Amazon SNS onderwerp
• Die vertrouensbeleid van 'n IAM rol wat deur 'n gebruiker aanvaar kan word

As jy 'n hulpbron wil toegang via CLI wat MFA nagaan, moet jy GetSessionToken aanroep. Dit sal vir jou 'n token gee met inligting oor MFA.
Let daarop dat AssumeRole geloofsbriewe nie hierdie inligting bevat nie.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

As hier genoem, daar is 'n baie verskillende gevalle waar MFA nie gebruik kan word nie.

IAM gebruikersgroepe

'n IAM gebruikersgroep is 'n manier om beleide aan verskeie gebruikers op een slag te koppel, wat dit makliker kan maak om die toestemmings vir daardie gebruikers te bestuur. Rol en groepe kan nie deel wees van 'n groep nie.

Jy kan 'n identiteitsgebaseerde beleid aan 'n gebruikersgroep koppel sodat al die gebruikers in die gebruikersgroep die beleid se toestemmings ontvang. Jy kan nie 'n gebruikersgroep as 'n Principal in 'n beleid identifiseer (soos 'n hulpbron-gebaseerde beleid) nie, omdat groepe met toestemmings verband hou, nie verifikasie nie, en principals is geverifieerde IAM entiteite.

Hier is 'n paar belangrike eienskappe van gebruikersgroepe:

• 'n gebruikers groep kan baie gebruikers bevat, en 'n gebruiker kan tot verskeie groepe behoort.
• Gebruikersgroepe kan nie geneste wees nie; hulle kan slegs gebruikers bevat, nie ander gebruikersgroepe nie.
• Daar is geen standaard gebruikersgroep wat outomaties al die gebruikers in die AWS-rekening insluit nie. As jy 'n gebruikersgroep soos dit wil hê, moet jy dit skep en elke nuwe gebruiker daaraan toewys.
• Die aantal en grootte van IAM hulpbronne in 'n AWS-rekening, soos die aantal groepe, en die aantal groepe waarvan 'n gebruiker 'n lid kan wees, is beperk. Vir meer inligting, sien IAM en AWS STS kwotas.

IAM rolle

'n IAM rol is baie soortgelyk aan 'n gebruiker, in die sin dat dit 'n identiteit met toestemmingbeleide is wat bepaal wat dit kan en nie kan doen in AWS nie. egter, 'n rol het nie enige geloofsbriewe (wagwoord of toegang sleutels) wat daarmee geassosieer is nie. In plaas daarvan om uniek aan een persoon geassosieer te wees, is 'n rol bedoel om aangenome te word deur enigeen wat dit nodig het (en genoeg perms het). 'n IAM gebruiker kan 'n rol aanvaar om tydelik verskillende toestemmings vir 'n spesifieke taak aan te neem. 'n rol kan toegeken word aan 'n gefedereerde gebruiker wat aanmeld deur 'n eksterne identiteitsverskaffer te gebruik in plaas van IAM.

'n IAM rol bestaan uit twee tipes beleide: 'n vertrouensbeleid, wat nie leeg kan wees nie, wat definieer wie die rol kan aanvaar, en 'n toestemmingsbeleid, wat nie leeg kan wees nie, wat definieer wat dit kan toegang.

AWS Sekuriteits Token Diens (STS)

AWS Sekuriteits Token Diens (STS) is 'n webdiens wat die uitreiking van tydelike, beperkte bevoegdhede fasiliteer. Dit is spesifiek ontwerp vir:

Tydelike geloofsbriewe in IAM

Tydelike geloofsbriewe word hoofsaaklik gebruik met IAM rolle, maar daar is ook ander gebruike. Jy kan tydelike geloofsbriewe aan vra wat 'n meer beperkte stel toestemmings het as jou standaard IAM gebruiker. Dit verhoed dat jy per ongeluk take uitvoer wat nie toegelaat word deur die meer beperkte geloofsbriewe nie. 'n voordeel van tydelike geloofsbriewe is dat hulle outomaties verval na 'n bepaalde tydperk. Jy het beheer oor die duur waarvoor die geloofsbriewe geldig is.

Beleide

Beleidstoestemmings

Word gebruik om toestemmings toe te ken. Daar is 2 tipes:

• AWS bestuurde beleide (voorgeskrewe deur AWS)
• Klant bestuurde beleide: Geconfigureer deur jou. Jy kan beleide skep gebaseer op AWS bestuurde beleide (een van hulle wysig en jou eie skep), deur die beleidgenerator te gebruik (n GUI-weergave wat jou help om toestemmings toe te ken en te weier) of jou eie te skryf.

Deur standaard toegang is weggeneem, toegang sal toegestaan word as 'n eksplisiete rol gespesifiseer is.
As enkele "Weier" bestaan, sal dit die "Toelaat" oorskry, behalwe vir versoeke wat die AWS-rekening se wortel sekuriteitsgeloofsbriewe gebruik (wat standaard toegelaat word).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

Die globale velde wat gebruik kan word vir voorwaardes in enige diens is hier gedokumenteer.
Die spesifieke velde wat gebruik kan word vir voorwaardes per diens is hier gedokumenteer.

Inline Beleide

Hierdie tipe beleide is direk toegeken aan 'n gebruiker, groep of rol. Dan verskyn hulle nie in die Beleide lys nie soos enige ander een kan hulle gebruik.
Inline beleide is nuttig as jy wil 'n streng een-tot-een verhouding tussen 'n beleid en die identiteit wat dit toegepas word, handhaaf. Byvoorbeeld, jy wil seker maak dat die toestemmings in 'n beleid nie per ongeluk aan 'n identiteit anders as die een waarvoor hulle bedoel is, toegeken word nie. Wanneer jy 'n inline beleid gebruik, kan die toestemmings in die beleid nie per ongeluk aan die verkeerde identiteit geheg word nie. Boonop, wanneer jy die AWS Bestuurskonsol gebruik om daardie identiteit te verwyder, word die beleide wat in die identiteit ingebed is, ook verwyder. Dit is omdat hulle deel van die hoof entiteit is.

Hulpbron Emmer Beleide

Hierdie is beleide wat in hulpbronne gedefinieer kan word. Nie alle hulpbronne van AWS ondersteun hulle nie.

As 'n hoof nie 'n eksplisiete weiering op hulle het nie, en 'n hulpbronbeleid hulle toegang gee, dan word hulle toegelaat.

IAM Grense

IAM grense kan gebruik word om die toestemmings wat 'n gebruiker of rol toegang tot moet hê, te beperk. Op hierdie manier, selfs al word 'n ander stel toestemmings aan die gebruiker toegeken deur 'n ander beleid, sal die operasie misluk as hy probeer om hulle te gebruik.

'n Grens is net 'n beleid wat aan 'n gebruiker geheg is wat die maksimum vlak van toestemmings wat die gebruiker of rol kan hê, aandui. So, selfs al het die gebruiker Administrateur toegang, as die grens aandui dat hy slegs S· emmers kan lees, is dit die maksimum wat hy kan doen.

Dit, SCPs en die beginsel van die minste voorreg is die maniere om te beheer dat gebruikers nie meer toestemmings het as wat hulle nodig het nie.

Sessie Beleide

'n Sessie beleid is 'n beleid wat ingestel word wanneer 'n rol aanvaar word op een of ander manier. Dit sal soos 'n IAM grens vir daardie sessie wees: Dit beteken dat die sessie beleid nie toestemmings toeken nie, maar beperk hulle tot diegene wat in die beleid aangedui word (met die maksimum toestemmings wat die rol het).

Dit is nuttig vir veiligheidsmaatreëls: Wanneer 'n admin 'n baie bevoorregte rol gaan aanvaar, kan hy die toestemming beperk tot slegs diegene wat in die sessie beleid aangedui word in die geval dat die sessie gecompromitteer word.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

Note dat AWS dalk sessiebeleide aan sessies kan voeg wat gegenereer gaan word weens derde redes. Byvoorbeeld, in nie-geverifieerde cognito aangeneemde rolle sal AWS standaard (met verbeterde verifikasie) sessie-akkrediteer met 'n sessiebeleid genereer wat die dienste wat die sessie kan toegang hê, beperk tot die volgende lys.

As jy dus op 'n stadium die fout "… omdat geen sessiebeleid dit toelaat nie …" teëkom, en die rol toegang het om die aksie uit te voer, is dit omdat daar 'n sessiebeleid is wat dit verhinder.

Identiteitsfederasie

Identiteitsfederasie laat gebruikers van identiteitsverskaffers wat eksterne is tot AWS toe om AWS-hulpbronne veilig te benader sonder om AWS-gebruikersakkrediteer van 'n geldige IAM-gebruikersrekening te verskaf.
'n Voorbeeld van 'n identiteitsverskaffer kan jou eie korporatiewe Microsoft Active Directory (via SAML) of OpenID dienste (soos Google) wees. Gefedereerde toegang sal dan die gebruikers binne dit toelaat om AWS te benader.

Om hierdie vertroue te konfigureer, word 'n IAM Identiteitsverskaffer gegenereer (SAML of OAuth) wat die ander platform sal vertrou. Dan word ten minste een IAM rol (wat vertrou) aan die Identiteitsverskaffer toegeken. As 'n gebruiker van die vertroude platform AWS benader, sal hy as die genoemde rol toegang hê.

IAM Identiteitsentrum

AWS IAM Identiteitsentrum (opvolger van AWS Enkelteken) brei die vermoëns van AWS Identiteits- en Toegangsbestuur (IAM) uit om 'n sentraal plek te bied wat die administrasie van gebruikers en hul toegang tot AWS rekeninge en wolktoepassings saambring.

Die aanmelddomein gaan iets soos <user_input>.awsapps.com wees.

Om gebruikers aan te meld, is daar 3 identiteitsbronne wat gebruik kan word:

• Identiteitsentrum Gids: Gereelde AWS gebruikers
• Aktiewe Gids: Ondersteun verskillende konnektore
• Eksterne Identiteitsverskaffer: Alle gebruikers en groepe kom van 'n eksterne Identiteitsverskaffer (IdP)

In die eenvoudigste geval van die Identiteitsentrum gids, sal die Identiteitsentrum 'n lys van gebruikers & groepe hê en sal in staat wees om beleide aan hulle toe te ken vir enige van die rekeninge van die organisasie.

Om toegang aan 'n Identiteitsentrum gebruiker/groep tot 'n rekening te gee, sal 'n SAML Identiteitsverskaffer wat die Identiteitsentrum vertrou, geskep word, en 'n rol wat die Identiteitsverskaffer met die aangeduide beleide vertrou, sal in die bestemmingsrekening geskep word.

AwsSSOInlinePolicy

Dit is moontlik om toestemmings via inline beleide aan rolle wat via IAM Identiteitsentrum geskep is, te gee. Die rolle wat in die rekeninge geskep word wat inline beleide in AWS Identiteitsentrum ontvang, sal hierdie toestemmings in 'n inline beleid genaamd AwsSSOInlinePolicy hê.

Daarom, selfs al sien jy 2 rolle met 'n inline beleid genaamd AwsSSOInlinePolicy, beteken dit nie dat dit dieselfde toestemmings het nie.

Kruisrekening Vertroue en Rolle

'n gebruiker (wat vertrou) kan 'n Kruisrekening Rol met sommige beleide skep en dan 'n ander gebruiker (wat vertrou) toelaat om sy rekening te benader maar slegs met die toegang wat in die nuwe rolbeleide aangedui is. Om dit te skep, skep eenvoudig 'n nuwe Rol en kies Kruisrekening Rol. Rolle vir Kruisrekening Toegang bied twee opsies. Om toegang te bied tussen AWS rekeninge wat jy besit, en om toegang te bied tussen 'n rekening wat jy besit en 'n derdeparty AWS rekening.
Dit word aanbeveel om die gebruiker wat vertrou is spesifiek aan te dui en nie 'n generiese ding te plaas nie, want anders kan ander geverifieerde gebruikers soos gefedereerde gebruikers ook hierdie vertroue misbruik.

AWS Eenvoudige AD

Nie ondersteun nie:

• Vertrouensverhoudings
• AD Admin Sentrum
• Volledige PS API ondersteuning
• AD Herwinningsblik
• Groep Gemanagte Diensrekeninge
• Skema-uitbreidings
• Geen Direkte toegang tot OS of Instansies nie

Web Federasie of OpenID Verifikasie

Die toepassing gebruik die AssumeRoleWithWebIdentity om tydelike akkrediteer te skep. Dit gee egter nie toegang tot die AWS-konsol nie, net toegang tot hulpbronne binne AWS.

Ander IAM opsies

• Jy kan 'n wagwoordbeleid instelling opsies soos minimum lengte en wagwoordvereistes stel.
• Jy kan "Akkrediteer Verslag" aflaai met inligting oor huidige akkrediteer (soos gebruikers skeppingstyd, is wagwoord geaktiveer...). Jy kan 'n akkrediteer verslag genereer so dikwels as een keer elke vier uur.

AWS Identiteits- en Toegangsbestuur (IAM) bied fyn-graad toegangbeheer oor al die AWS. Met IAM kan jy spesifiseer wie toegang het tot watter dienste en hulpbronne, en onder watter omstandighede. Met IAM beleide bestuur jy toestemmings aan jou werksmag en stelsels om minste-bevoegdheidstoestemmings te verseker.

IAM ID Vooraf

In hierdie bladsy kan jy die IAM ID vooraf van sleutels vind, afhangende van hul aard:

ABIA	AWS STS diens draer token
ACCA	Konteks-spesifieke akkrediteer
AGPA	Gebruikersgroep
AIDA	IAM gebruiker
AIPA	Amazon EC2 instansieprofiel
AKIA	Toegangssleutel
ANPA	Gemanagte beleid
ANVA	Weergawe in 'n gemanagte beleid
APKA	Publieke sleutel
AROA	Rol
ASCA	Sertifikaat
ASIA	Tydelike (AWS STS) toegangssleutel ID's gebruik hierdie vooraf, maar is uniek slegs in kombinasie met die geheime toegangssleutel en die sessietoken.

Aanbevole toestemmings om rekeninge te oudit

Die volgende voorregte bied verskeie lees toegang van metadata:

• arn:aws:iam::aws:policy/SecurityAudit
• arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
• codebuild:ListProjects
• config:Describe*
• cloudformation:ListStacks
• logs:DescribeMetricFilters
• directconnect:DescribeConnections
• dynamodb:ListTables

Verskeie

CLI Verifikasie

Om 'n gereelde gebruiker te laat verifieer by AWS via CLI, moet jy lokale akkrediteer hê. Standaard kan jy dit handmatig in ~/.aws/credentials konfigureer of deur te loop aws configure.
In daardie lêer kan jy meer as een profiel hê, as geen profiel gespesifiseer word met die aws cli, sal die een genaamd [default] in daardie lêer gebruik word.
Voorbeeld van akkrediteer lêer met meer as 1 profiel:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
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.

You can use the ~/.aws/config file to aandui watter rolle om aan te neem, and then use the --profile param as usual (the assume-role will be performed in a transparent way for the user).
A config file example:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Met hierdie konfigurasie-lêer kan jy dan aws cli gebruik soos:

aws --profile acc2 ...

As jy op soek is na iets soortgelyks soos dit, maar vir die blaaier, kan jy die uitbreiding AWS Extend Switch Roles kyk.

Verwysings

• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html
• https://aws.amazon.com/iam/
• https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html

{{#include ../../../banners/hacktricks-training.md}}