gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-02-05 11:26:11 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/

Browse Source
This commit is contained in:
Translator
2024-12-31 20:24:43 +00:00
parent 10e2881a9b
commit 9ce07d92a3
245 changed files with 9883 additions and 12659 deletions
Download Patch File Download Diff File Expand all files Collapse all files

378
src/pentesting-cloud/aws-security/aws-basic-information/README.md
View File

@@ -1,331 +1,321 @@
# AWS - Basic Information
# AWS - Osnovne Informacije
{{#include ../../../banners/hacktricks-training.md}}
## Organization Hierarchy
## Hijerarhija Organizacije
![](<../../../images/image (151).png>)
### Accounts
### Računi
In AWS there is a **root account,** which is the **parent container for all the accounts** for your **organization**. However, you don't need to use that account to deploy resources, you can create **other accounts to separate different AWS** infrastructures between them.
U AWS-u postoji **root račun**, koji je **glavni kontejner za sve račune** vaše **organizacije**. Međutim, ne morate koristiti taj račun za implementaciju resursa, možete kreirati **druge račune kako biste odvojili različite AWS** infrastrukture između njih.
This is very interesting from a **security** point of view, as **one account won't be able to access resources from other account** (except bridges are specifically created), so this way you can create boundaries between deployments.
To je veoma zanimljivo sa **bezbednosnog** stanovišta, jer **jedan račun neće moći da pristupi resursima drugog računa** (osim ako su mostovi posebno kreirani), tako da na ovaj način možete postaviti granice između implementacija.
Therefore, there are **two types of accounts in an organization** (we are talking about AWS accounts and not User accounts): a single account that is designated as the management account, and one or more member accounts.
Stoga, postoje **dva tipa računa u organizaciji** (govorimo o AWS računima, a ne o korisničkim računima): jedan jedini račun koji je označen kao račun za upravljanje, i jedan ili više članova računa.
- The **management account (the root account)** is the account that you use to create the organization. From the organization's management account, you can do the following:
- **Račun za upravljanje (root račun)** je račun koji koristite za kreiranje organizacije. Iz računa za upravljanje organizacijom, možete uraditi sledeće:
- Create accounts in the organization
- Invite other existing accounts to the organization
- Remove accounts from the organization
- Manage invitations
- Apply policies to entities (roots, OUs, or accounts) within the organization
- Enable integration with supported AWS services to provide service functionality across all of the accounts in the organization.
- It's possible to login as the root user using the email and password used to create this root account/organization.
- Kreirati račune u organizaciji
- Pozvati druge postojeće račune u organizaciju
- Ukloniti račune iz organizacije
- Upravljati pozivnicama
- Primeni politike na entitete (root, OU ili račune) unutar organizacije
- Omogućiti integraciju sa podržanim AWS uslugama kako bi se obezbedila funkcionalnost usluga širom svih računa u organizaciji.
- Moguće je prijaviti se kao root korisnik koristeći email i lozinku korišćene za kreiranje ovog root računa/organizacije.
The management account has the **responsibilities of a payer account** and is responsible for paying all charges that are accrued by the member accounts. You can't change an organization's management account.
- **Member accounts** make up all of the rest of the accounts in an organization. An account can be a member of only one organization at a time. You can attach a policy to an account to apply controls to only that one account.
- Member accounts **must use a valid email address** and can have a **name**, in general they wont be able to manage the billing (but they might be given access to it).
Račun za upravljanje ima **odgovornosti računa za plaćanje** i odgovoran je za plaćanje svih troškova koje generišu članovi računi. Ne možete promeniti račun za upravljanje organizacijom.
- **Članovi računi** čine sve ostale račune u organizaciji. Račun može biti član samo jedne organizacije u isto vreme. Možete prikačiti politiku na račun kako biste primenili kontrole samo na taj jedan račun.
- Članovi računi **moraju koristiti važeću email adresu** i mogu imati **ime**, generalno neće moći da upravljaju naplatom (ali im može biti dat pristup tome).
```
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
```
### **Organizacione jedinice**
### **Organization Units**
Accounts can be grouped in **Organization Units (OU)**. This way, you can create **policies** for the Organization Unit that are going to be **applied to all the children accounts**. Note that an OU can have other OUs as children.
Računi se mogu grupisati u **organizacione jedinice (OU)**. Na ovaj način, možete kreirati **politike** za organizacionu jedinicu koje će biti **primenjene na sve podračune**. Imajte na umu da OU može imati druge OU kao decu.
```bash
# 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)
A **service control policy (SCP)** is a policy that specifies the services and actions that users and roles can use in the accounts that the SCP affects. SCPs are **similar to IAM** permissions policies except that they **don't grant any permissions**. Instead, SCPs specify the **maximum permissions** for an organization, organizational unit (OU), or account. When you attach a SCP to your organization root or an OU, the **SCP limits permissions for entities in member accounts**.
**Politika kontrole usluga (SCP)** je politika koja specificira usluge i akcije koje korisnici i uloge mogu koristiti u nalozima na koje SCP utiče. SCP-ovi su **slični IAM** politikama dozvola osim što **ne dodeljuju nikakve dozvole**. Umesto toga, SCP-ovi specificiraju **maksimalne dozvole** za organizaciju, organizacionu jedinicu (OU) ili nalog. Kada prikačite SCP na koren vaše organizacije ili na OU, **SCP ograničava dozvole za entitete u članicama naloga**.
This is the ONLY way that **even the root user can be stopped** from doing something. For example, it could be used to stop users from disabling CloudTrail or deleting backups.\
The only way to bypass this is to compromise also the **master account** that configures the SCPs (master account cannot be blocked).
Ovo je JEDINI način na koji **čak i korisnik sa root privilegijama može biti sprečen** da uradi nešto. Na primer, može se koristiti da se spreči korisnike da onemoguće CloudTrail ili obrišu rezervne kopije.\
Jedini način da se to zaobiđe je da se kompromituje i **glavni nalog** koji konfiguriše SCP-ove (glavni nalog ne može biti blokiran).
> [!WARNING]
> Note that **SCPs only restrict the principals in the account**, so other accounts are not affected. This means having an SCP deny `s3:GetObject` will not stop people from **accessing a public S3 bucket** in your account.
> Imajte na umu da **SCP-ovi samo ograničavaju principe u nalogu**, tako da drugi nalozi nisu pogođeni. To znači da imati SCP koji odbija `s3:GetObject` neće sprečiti ljude da **pristupaju javnom S3 bucket-u** u vašem nalogu.
SCP examples:
Primeri SCP-a:
- Deny the root account entirely
- Only allow specific regions
- Only allow white-listed services
- Deny GuardDuty, CloudTrail, and S3 Public Block Access from
- Odbijanje glavnog naloga u potpunosti
- Dozvoliti samo specifične regione
- Dozvoliti samo usluge sa bele liste
- Odbijanje GuardDuty, CloudTrail i S3 javnog blokiranja pristupa od
being disabled
biti onemogućeni
- Deny security/incident response roles from being deleted or
- Odbijanje uloga za bezbednost/odgovor na incidente od
modified.
biti obrisane ili
- Deny backups from being deleted.
- Deny creating IAM users and access keys
modifikovane.
Find **JSON examples** in [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)
- Odbijanje brisanja rezervnih kopija.
- Odbijanje kreiranja IAM korisnika i pristupnih ključeva
Pronađite **JSON primere** u [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)
### ARN
**Amazon Resource Name** is the **unique name** every resource inside AWS has, its composed like this:
**Amazon Resource Name** je **jedinstveno ime** koje svaki resurs unutar AWS-a ima, sastoji se ovako:
```
arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
```
Note that there are 4 partitions in AWS but only 3 ways to call them:
Napomena da postoje 4 particije u AWS-u, ali samo 3 načina da ih pozovete:
- AWS Standard: `aws`
- AWS China: `aws-cn`
- AWS US public Internet (GovCloud): `aws-us-gov`
- AWS US javni Internet (GovCloud): `aws-us-gov`
- AWS Secret (US Classified): `aws`
## IAM - Identity and Access Management
## IAM - Upravljanje identitetom i pristupom
IAM is the service that will allow you to manage **Authentication**, **Authorization** and **Access Control** inside your AWS account.
IAM je usluga koja će vam omogućiti da upravljate **autentifikacijom**, **autorizacijom** i **kontrolom pristupa** unutar vašeg AWS naloga.
- **Authentication** - Process of defining an identity and the verification of that identity. This process can be subdivided in: Identification and verification.
- **Authorization** - Determines what an identity can access within a system once it's been authenticated to it.
- **Access Control** - The method and process of how access is granted to a secure resource
- **Autentifikacija** - Proces definisanja identiteta i verifikacije tog identiteta. Ovaj proces se može podeliti na: Identifikaciju i verifikaciju.
- **Autorizacija** - Određuje šta identitet može da pristupi unutar sistema nakon što je autentifikovan.
- **Kontrola pristupa** - Metod i proces kako se pristup dodeljuje sigurnom resursu.
IAM can be defined by its ability to manage, control and govern authentication, authorization and access control mechanisms of identities to your resources within your AWS account.
IAM se može definisati po svojoj sposobnosti da upravlja, kontroliše i reguliše mehanizme autentifikacije, autorizacije i kontrole pristupa identiteta vašim resursima unutar vašeg AWS naloga.
### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
### [AWS nalog root korisnika](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
When you first create an Amazon Web Services (AWS) account, you begin with a single sign-in identity that has **complete access to all** AWS services and resources in the account. This is the AWS account _**root user**_ and is accessed by signing in with the **email address and password that you used to create the account**.
Kada prvi put kreirate Amazon Web Services (AWS) nalog, počinjete sa jednim identitetom za prijavu koji ima **potpun pristup svim** AWS uslugama i resursima u nalogu. Ovo je _**root korisnik**_ AWS naloga i pristupa mu se prijavom sa **email adresom i lozinkom koje ste koristili za kreiranje naloga**.
Note that a new **admin user** will have **less permissions that the root user**.
Napomena da novi **admin korisnik** ima **manje dozvole od root korisnika**.
From a security point of view, it's recommended to create other users and avoid using this one.
Sa bezbednosnog stanovišta, preporučuje se kreiranje drugih korisnika i izbegavanje korišćenja ovog.
### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
### [IAM korisnici](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
An IAM _user_ is an entity that you create in AWS to **represent the person or application** that uses it to **interact with AWS**. A user in AWS consists of a name and credentials (password and up to two access keys).
IAM _korisnik_ je entitet koji kreirate u AWS-u da **predstavlja osobu ili aplikaciju** koja ga koristi za **interakciju sa AWS-om**. Korisnik u AWS-u se sastoji od imena i akreditiva (lozinka i do dva pristupna ključa).
When you create an IAM user, you grant it **permissions** by making it a **member of a user group** that has appropriate permission policies attached (recommended), or by **directly attaching policies** to the user.
Kada kreirate IAM korisnika, dodeljujete mu **dozvole** tako što ga činite **članom korisničke grupe** koja ima odgovarajuće politike dozvola (preporučeno), ili **direktno povezivanjem politika** sa korisnikom.
Users can have **MFA enabled to login** through the console. API tokens of MFA enabled users aren't protected by MFA. If you want to **restrict the access of a users API keys using MFA** you need to indicate in the policy that in order to perform certain actions MFA needs to be present (example [**here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
Korisnici mogu imati **omogućen MFA za prijavu** putem konzole. API tokeni korisnika sa omogućenim MFA nisu zaštićeni MFA. Ako želite da **ograničite pristup API ključevima korisnika koristeći MFA**, morate naznačiti u politici da je za izvršavanje određenih radnji MFA potrebno (primer [**ovde**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
#### CLI
- **Access Key ID**: 20 random uppercase alphanumeric characters like AKHDNAPO86BSHKDIRYT
- **Secret access key ID**: 40 random upper and lowercase characters: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (It's not possible to retrieve lost secret access key IDs).
- **ID pristupnog ključa**: 20 nasumičnih velikih alfanumeričkih karaktera kao što su AKHDNAPO86BSHKDIRYT
- **ID tajnog pristupnog ključa**: 40 nasumičnih velikih i malih karaktera: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Nije moguće povratiti izgubljene ID-ove tajnog pristupnog ključa).
Whenever you need to **change the Access Key** this is the process you should follow:\
Kad god trebate da **promenite pristupni ključ**, ovo je proces koji treba da pratite:\
&#xNAN;_&#x43;reate a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key_
### MFA - Multi Factor Authentication
### MFA - Višefaktorska autentifikacija
It's used to **create an additional factor for authentication** in addition to your existing methods, such as password, therefore, creating a multi-factor level of authentication.\
You can use a **free virtual application or a physical device**. You can use apps like google authentication for free to activate a MFA in AWS.
Koristi se za **kreiranje dodatnog faktora za autentifikaciju** pored vaših postojećih metoda, kao što je lozinka, čime se stvara višefaktorski nivo autentifikacije.\
Možete koristiti **besplatnu virtuelnu aplikaciju ili fizički uređaj**. Možete koristiti aplikacije poput Google autentifikacije besplatno za aktivaciju MFA u AWS-u.
Policies with MFA conditions can be attached to the following:
Politike sa MFA uslovima mogu se povezati sa sledećim:
- An IAM user or group
- A resource such as an Amazon S3 bucket, Amazon SQS queue, or Amazon SNS topic
- The trust policy of an IAM role that can be assumed by a user
If you want to **access via CLI** a resource that **checks for MFA** you need to call **`GetSessionToken`**. That will give you a token with info about MFA.\
Note that **`AssumeRole` credentials don't contain this information**.
- IAM korisnikom ili grupom
- Resursom kao što je Amazon S3 bucket, Amazon SQS queue ili Amazon SNS topic
- Politika poverenja IAM uloge koju može preuzeti korisnik
Ako želite da **pristupite putem CLI** resursu koji **proverava MFA**, morate pozvati **`GetSessionToken`**. To će vam dati token sa informacijama o MFA.\
Napomena da **`AssumeRole` akreditivi ne sadrže ove informacije**.
```bash
aws sts get-session-token --serial-number <arn_device> --token-code <code>
```
As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), postoje mnogi različiti slučajevi gde **MFA ne može biti korišćen**.
As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), there are a lot of different cases where **MFA cannot be used**.
### [IAM korisničke grupe](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
### [IAM user groups](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
IAM [korisnička grupa](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) je način da se **prikače politike više korisnika** u isto vreme, što može olakšati upravljanje dozvolama za te korisnike. **Uloge i grupe ne mogu biti deo grupe**.
An IAM [user group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) is a way to **attach policies to multiple users** at one time, which can make it easier to manage the permissions for those users. **Roles and groups cannot be part of a group**.
Možete prikačiti **politiku zasnovanu na identitetu korisničkoj grupi** tako da svi **korisnici** u korisničkoj grupi **dobiju dozvole politike**. **Ne možete** identifikovati **korisničku grupu** kao **`Principal`** u **politici** (kao što je politika zasnovana na resursima) jer se grupe odnose na dozvole, a ne na autentifikaciju, a principi su autentifikovani IAM entiteti.
You can attach an **identity-based policy to a user group** so that all of the **users** in the user group **receive the policy's permissions**. You **cannot** identify a **user group** as a **`Principal`** in a **policy** (such as a resource-based policy) because groups relate to permissions, not authentication, and principals are authenticated IAM entities.
Evo nekih važnih karakteristika korisničkih grupa:
Here are some important characteristics of user groups:
- **Korisnička grupa** može **sadržati mnogo korisnika**, a **korisnik** može **pripadati više grupa**.
- **Korisničke grupe ne mogu biti ugnježdene**; mogu sadržati samo korisnike, ne i druge korisničke grupe.
- Ne postoji **podrazumevana korisnička grupa koja automatski uključuje sve korisnike u AWS nalogu**. Ako želite da imate takvu korisničku grupu, morate je kreirati i dodeliti svakom novom korisniku.
- Broj i veličina IAM resursa u AWS nalogu, kao što su broj grupa i broj grupa kojima korisnik može biti član, su ograničeni. Za više informacija, pogledajte [IAM i AWS STS kvote](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
- A user **group** can **contain many users**, and a **user** can **belong to multiple groups**.
- **User groups can't be nested**; they can contain only users, not other user groups.
- There is **no default user group that automatically includes all users in the AWS account**. If you want to have a user group like that, you must create it and assign each new user to it.
- The number and size of IAM resources in an AWS account, such as the number of groups, and the number of groups that a user can be a member of, are limited. For more information, see [IAM and AWS STS quotas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
### [IAM uloge](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
### [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
IAM **uloga** je vrlo **slična** **korisniku**, jer je to **identitet sa politikama dozvola koje određuju šta** može i ne može da radi u AWS-u. Međutim, uloga **nema nikakve akreditive** (lozinku ili pristupne ključeve) povezane sa njom. Umesto da bude jedinstveno povezana sa jednom osobom, uloga je namenjena da bude **preuzeta od strane bilo koga ko je treba (i ima dovoljno dozvola)**. **IAM korisnik može preuzeti ulogu da privremeno** preuzme različite dozvole za određeni zadatak. Uloga može biti **dodeljena** [**federisanom korisniku**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) koji se prijavljuje koristeći eksternog provajdera identiteta umesto IAM-a.
An IAM **role** is very **similar** to a **user**, in that it is an **identity with permission policies that determine what** it can and cannot do in AWS. However, a role **does not have any credentials** (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be **assumable by anyone who needs it (and have enough perms)**. An **IAM user can assume a role to temporarily** take on different permissions for a specific task. A role can be **assigned to a** [**federated user**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) who signs in by using an external identity provider instead of IAM.
An IAM role consists of **two types of policies**: A **trust policy**, which cannot be empty, defining **who can assume** the role, and a **permissions policy**, which cannot be empty, defining **what it can access**.
IAM uloga se sastoji od **dvaju tipova politika**: **politika poverenja**, koja ne može biti prazna, definišući **ko može preuzeti** ulogu, i **politika dozvola**, koja ne može biti prazna, definišući **šta može pristupiti**.
#### AWS Security Token Service (STS)
AWS Security Token Service (STS) is a web service that facilitates the **issuance of temporary, limited-privilege credentials**. It is specifically tailored for:
AWS Security Token Service (STS) je veb servis koji olakšava **izdavanje privremenih, ograničenih akreditiva**. Specijalno je prilagođen za:
### [Temporary credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
### [Privremeni akreditivi u IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
**Temporary credentials are primarily used with IAM roles**, but there are also other uses. You can request temporary credentials that have a more restricted set of permissions than your standard IAM user. This **prevents** you from **accidentally performing tasks that are not permitted** by the more restricted credentials. A benefit of temporary credentials is that they expire automatically after a set period of time. You have control over the duration that the credentials are valid.
**Privremeni akreditivi se prvenstveno koriste sa IAM ulogama**, ali postoje i druge upotrebe. Možete zatražiti privremene akreditive koji imaju ograničeniji skup dozvola od vašeg standardnog IAM korisnika. Ovo **sprečava** vas od **slučajnog obavljanja zadataka koji nisu dozvoljeni** sa ograničenim akreditivima. Prednost privremenih akreditiva je ta što automatski ističu nakon određenog vremenskog perioda. Imate kontrolu nad trajanjem tokom kojeg su akreditivi validni.
### Policies
### Politike
#### Policy Permissions
#### Dozvole politike
Are used to assign permissions. There are 2 types:
Koriste se za dodeljivanje dozvola. Postoje 2 tipa:
- AWS managed policies (preconfigured by AWS)
- Customer Managed Policies: Configured by you. You can create policies based on AWS managed policies (modifying one of them and creating your own), using the policy generator (a GUI view that helps you granting and denying permissions) or writing your own..
By **default access** is **denied**, access will be granted if an explicit role has been specified.\
If **single "Deny" exist, it will override the "Allow"**, except for requests that use the AWS account's root security credentials (which are allowed by default).
- AWS upravljane politike (prekonfigurisane od strane AWS-a)
- Politike koje upravlja korisnik: Konfigurišete ih vi. Možete kreirati politike zasnovane na AWS upravljanim politikama (modifikujući jednu od njih i kreirajući svoju), koristeći generator politika (GUI prikaz koji vam pomaže u dodeljivanju i odbijanju dozvola) ili pišući svoje.
Po **podrazumevanju, pristup** je **odbijen**, pristup će biti odobren ako je eksplicitna uloga navedena.\
Ako **jedna "Odbij" postoji, ona će nadjačati "Dozvoli"**, osim za zahteve koji koriste korenske bezbednosne akreditive AWS naloga (koji su podrazumevano dozvoljeni).
```javascript
{
"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"}
}
}
]
"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"}
}
}
]
}
```
The [global fields that can be used for conditions in any service are documented here](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
The [specific fields that can be used for conditions per service are documented here](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
#### Inline Policies
This kind of policies are **directly assigned** to a user, group or role. Then, they do not appear in the Policies list as any other one can use them.\
Inline policies are useful if you want to **maintain a strict one-to-one relationship between a policy and the identity** that it's applied to. For example, you want to be sure that the permissions in a policy are not inadvertently assigned to an identity other than the one they're intended for. When you use an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong identity. In addition, when you use the AWS Management Console to delete that identity, the policies embedded in the identity are deleted as well. That's because they are part of the principal entity.
Ova vrsta politika je **direktno dodeljena** korisniku, grupi ili ulozi. Tada se ne pojavljuju na listi politika kao što to može biti slučaj sa bilo kojom drugom.\
Inline politike su korisne ako želite da **održite strogu jedan-na-jedan vezu između politike i identiteta** na koji se primenjuju. Na primer, želite da budete sigurni da dozvole u politici nisu nenamerno dodeljene identitetu osim onog za koji su namenjene. Kada koristite inline politiku, dozvole u politici ne mogu biti nenamerno povezane sa pogrešnim identitetom. Pored toga, kada koristite AWS Management Console za brisanje tog identiteta, politike ugrađene u identitet se takođe brišu. To je zato što su deo glavne entiteta.
#### Resource Bucket Policies
These are **policies** that can be defined in **resources**. **Not all resources of AWS supports them**.
Ovo su **politike** koje se mogu definisati u **resursima**. **Nisu svi resursi AWS-a podržavaju njih**.
If a principal does not have an explicit deny on them, and a resource policy grants them access, then they are allowed.
Ako glavni entitet nema eksplicitnu zabranu na njih, a politika resursa im omogućava pristup, tada su dozvoljeni.
### IAM Boundaries
IAM boundaries can be used to **limit the permissions a user or role should have access to**. This way, even if a different set of permissions are granted to the user by a **different policy** the operation will **fail** if he tries to use them.
IAM granice se mogu koristiti za **ograničavanje dozvola kojima korisnik ili uloga treba da imaju pristup**. Na ovaj način, čak i ako se korisniku dodeli drugačiji skup dozvola putem **druge politike**, operacija će **neuspeti** ako pokuša da ih koristi.
A boundary is just a policy attached to a user which **indicates the maximum level of permissions the user or role can have**. So, **even if the user has Administrator access**, if the boundary indicates he can only read S· buckets, that's the maximum he can do.
Granica je samo politika koja je povezana sa korisnikom i **ukazuje na maksimalni nivo dozvola koje korisnik ili uloga mogu imati**. Dakle, **čak i ako korisnik ima Administrator pristup**, ako granica ukazuje da može samo da čita S· kante, to je maksimum što može da uradi.
**This**, **SCPs** and **following the least privilege** principle are the ways to control that users doesn't have more permissions than the ones he needs.
**Ovo**, **SCPs** i **pridržavanje principa minimalnih privilegija** su načini da se kontroliše da korisnici nemaju više dozvola nego što im je potrebno.
### Session Policies
A session policy is a **policy set when a role is assumed** somehow. This will be like an **IAM boundary for that session**: This means that the session policy doesn't grant permissions but **restrict them to the ones indicated in the policy** (being the max permissions the ones the role has).
This is useful for **security meassures**: When an admin is going to assume a very privileged role he could restrict the permission to only the ones indicated in the session policy in case the session gets compromised.
Politika sesije je **politika postavljena kada se uloga preuzima** na neki način. Ovo će biti kao **IAM granica za tu sesiju**: To znači da politika sesije ne dodeljuje dozvole, već **ograničava ih na one koje su navedene u politici** (maksimalne dozvole su one koje uloga ima).
Ovo je korisno za **bezbednosne mere**: Kada administrator preuzima veoma privilegovanu ulogu, mogao bi da ograniči dozvolu samo na one koje su navedene u politici sesije u slučaju da sesija bude kompromitovana.
```bash
aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]
```
Napomena da po defaultu **AWS može dodati politike sesije sesijama** koje će biti generisane zbog trećih razloga. Na primer, u [neautentifikovanim cognito pretpostavljenim rolama](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) po defaultu (koristeći poboljšanu autentifikaciju), AWS će generisati **akreditiv sesije sa politikom sesije** koja ograničava usluge kojima sesija može pristupiti [**na sledeću listu**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
Note that by default **AWS might add session policies to sessions** that are going to be generated because of third reasons. For example, in [unauthenticated cognito assumed roles](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) by default (using enhanced authentication), AWS will generate **session credentials with a session policy** that limits the services that session can access [**to the following list**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
Stoga, ako se u nekom trenutku suočite sa greškom "... jer nijedna politika sesije ne dozvoljava ...", a uloga ima pristup za izvršenje akcije, to je zato što **postoji politika sesije koja to sprečava**.
Therefore, if at some point you face the error "... because no session policy allows the ...", and the role has access to perform the action, it's because **there is a session policy preventing it**.
### Identitetna federacija
### Identity Federation
Identitetna federacija **omogućava korisnicima iz identitetskih provajdera koji su eksterni** za AWS da sigurno pristupaju AWS resursima bez potrebe da dostavljaju AWS korisničke akreditive iz važećeg IAM korisničkog naloga.\
Primer identitetskog provajdera može biti vaša vlastita korporativna **Microsoft Active Directory** (putem **SAML**) ili **OpenID** usluga (kao što je **Google**). Federisani pristup će tada omogućiti korisnicima unutar njega da pristupaju AWS-u.
Identity federation **allows users from identity providers which are external** to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account.\
An example of an identity provider can be your own corporate **Microsoft Active Directory** (via **SAML**) or **OpenID** services (like **Google**). Federated access will then allow the users within it to access AWS.
Da biste konfigurisali ovo poverenje, generiše se **IAM identitetski provajder (SAML ili OAuth)** koji će **verovati** **drugoj platformi**. Zatim, najmanje jedna **IAM uloga se dodeljuje (verujuća) identitetskom provajderu**. Ako korisnik iz poverene platforme pristupi AWS-u, pristupaće kao pomenuta uloga.
To configure this trust, an **IAM Identity Provider is generated (SAML or OAuth)** that will **trust** the **other platform**. Then, at least one **IAM role is assigned (trusting) to the Identity Provider**. If a user from the trusted platform access AWS, he will be accessing as the mentioned role.
However, you will usually want to give a **different role depending on the group of the user** in the third party platform. Then, several **IAM roles can trust** the third party Identity Provider and the third party platform will be the one allowing users to assume one role or the other.
Međutim, obično ćete želeti da dodelite **različitu ulogu u zavisnosti od grupe korisnika** na trećoj strani. Tada, nekoliko **IAM uloga može verovati** trećem identitetskom provajderu, a treća platforma će biti ta koja omogućava korisnicima da preuzmu jednu ili drugu ulogu.
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
### IAM Identity Center
### IAM Identitetni Centar
AWS IAM Identity Center (successor to AWS Single Sign-On) expands the capabilities of AWS Identity and Access Management (IAM) to provide a **central plac**e that brings together **administration of users and their access to AWS** accounts and cloud applications.
AWS IAM Identitetni Centar (naslednik AWS Single Sign-On) proširuje mogućnosti AWS upravljanja identitetom i pristupom (IAM) kako bi pružio **centralno mesto** koje okuplja **administraciju korisnika i njihov pristup AWS** nalozima i cloud aplikacijama.
The login domain is going to be something like `<user_input>.awsapps.com`.
Domen za prijavu će biti nešto poput `<user_input>.awsapps.com`.
To login users, there are 3 identity sources that can be used:
Da bi se prijavili korisnici, postoje 3 izvora identiteta koji se mogu koristiti:
- Identity Center Directory: Regular AWS users
- Active Directory: Supports different connectors
- External Identity Provider: All users and groups come from an external Identity Provider (IdP)
- Identitetni Centar Direktorijum: Redovni AWS korisnici
- Active Directory: Podržava različite konektore
- Eksterni identitetski provajder: Svi korisnici i grupe dolaze iz eksternog identitetskog provajdera (IdP)
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
In the simplest case of Identity Center directory, the **Identity Center will have a list of users & groups** and will be able to **assign policies** to them to **any of the accounts** of the organization.
U najjednostavnijem slučaju direktorijuma Identitetnog Centra, **Identitetni Centar će imati listu korisnika i grupa** i moći će da **dodeli politike** njima za **bilo koji od naloga** organizacije.
In order to give access to a Identity Center user/group to an account a **SAML Identity Provider trusting the Identity Center will be created**, and a **role trusting the Identity Provider with the indicated policies will be created** in the destination account.
Da biste dali pristup korisniku/grupi Identitetnog Centra nalogu, **biće kreiran SAML identitetski provajder koji veruje Identitetnom Centru**, a **uloga koja veruje identitetskom provajderu sa navedenim politikama biće kreirana** u odredišnom nalogu.
#### AwsSSOInlinePolicy
It's possible to **give permissions via inline policies to roles created via IAM Identity Center**. The roles created in the accounts being given **inline policies in AWS Identity Center** will have these permissions in an inline policy called **`AwsSSOInlinePolicy`**.
Moguće je **dati dozvole putem inline politika rolama kreiranim putem IAM Identitetnog Centra**. Uloge kreirane u nalozima koje dobijaju **inline politike u AWS Identitetnom Centru** će imati ove dozvole u inline politici pod nazivom **`AwsSSOInlinePolicy`**.
Therefore, even if you see 2 roles with an inline policy called **`AwsSSOInlinePolicy`**, it **doesn't mean it has the same permissions**.
Stoga, čak i ako vidite 2 uloge sa inline politikom pod nazivom **`AwsSSOInlinePolicy`**, to **ne znači da imaju iste dozvole**.
### Cross Account Trusts and Roles
**A user** (trusting) can create a Cross Account Role with some policies and then, **allow another user** (trusted) to **access his account** but only **having the access indicated in the new role policies**. To create this, just create a new Role and select Cross Account Role. Roles for Cross-Account Access offers two options. Providing access between AWS accounts that you own, and providing access between an account that you own and a third party AWS account.\
It's recommended to **specify the user who is trusted and not put some generic thing** because if not, other authenticated users like federated users will be able to also abuse this trust.
**Korisnik** (verujući) može kreirati Cross Account ulogu sa nekim politikama i zatim **dozvoliti drugom korisniku** (verovanom) da **pristupi njegovom nalogu** ali samo **imajući pristup naznačen u novim politikama uloge**. Da biste to kreirali, jednostavno kreirajte novu ulogu i izaberite Cross Account ulogu. Uloge za pristup između naloga nude dve opcije. Pružanje pristupa između AWS naloga koje posedujete, i pružanje pristupa između naloga koji posedujete i trećeg AWS naloga.\
Preporučuje se da **precizirate korisnika koji je poveren i ne stavljate neku generičku stvar** jer u suprotnom, drugi autentifikovani korisnici poput federisanih korisnika će takođe moći da zloupotrebe ovo poverenje.
### AWS Simple AD
Not supported:
Nije podržano:
- Trust Relations
- AD Admin Center
- Full PS API support
- AD Recycle Bin
- Group Managed Service Accounts
- Schema Extensions
- No Direct access to OS or Instances
- Odnos poverenja
- AD Admin Centar
- Puna PS API podrška
- AD Kanta za reciklažu
- Grupa upravljanih servisnih naloga
- Proširenja šeme
- Nema direktan pristup OS-u ili instancama
#### Web Federation or OpenID Authentication
#### Web Federacija ili OpenID Autentifikacija
The app uses the AssumeRoleWithWebIdentity to create temporary credentials. However, this doesn't grant access to the AWS console, just access to resources within AWS.
Aplikacija koristi AssumeRoleWithWebIdentity za kreiranje privremenih akreditiva. Međutim, ovo ne daje pristup AWS konzoli, samo pristup resursima unutar AWS-a.
### Other IAM options
### Druge IAM opcije
- You can **set a password policy setting** options like minimum length and password requirements.
- You can **download "Credential Report"** with information about current credentials (like user creation time, is password enabled...). You can generate a credential report as often as once every **four hours**.
- Možete **postaviti podešavanje politike lozinke** kao što su minimalna dužina i zahtevi za lozinku.
- Možete **preuzeti "Izveštaj o akreditivima"** sa informacijama o trenutnim akreditivima (kao što su vreme kreiranja korisnika, da li je lozinka omogućena...). Možete generisati izveštaj o akreditivima koliko često želite, čak i jednom svaka **četiri sata**.
AWS Identity and Access Management (IAM) provides **fine-grained access control** across all of AWS. With IAM, you can specify **who can access which services and resources**, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to **ensure least-privilege permissions**.
AWS upravljanje identitetom i pristupom (IAM) pruža **fino podešavanje kontrole pristupa** širom celog AWS-a. Sa IAM-om, možete precizirati **ko može pristupiti kojim uslugama i resursima**, i pod kojim uslovima. Sa IAM politikama, upravljate dozvolama za vašu radnu snagu i sisteme kako biste **osigurali dozvole sa najmanjim privilegijama**.
### IAM ID Prefixes
### IAM ID Prefiksi
In [**this page**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) you can find the **IAM ID prefixe**d of keys depending on their nature:
Na [**ovoj stranici**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) možete pronaći **IAM ID prefikse** ključeva u zavisnosti od njihove prirode:
| ABIA | [AWS STS service bearer token](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| ABIA | [AWS STS servisni token nosilac](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ACCA | Context-specific credential |
| AGPA | User group |
| AIDA | IAM user |
| AIPA | Amazon EC2 instance profile |
| AKIA | Access key |
| ANPA | Managed policy |
| ANVA | Version in a managed policy |
| APKA | Public key |
| AROA | Role |
| ASCA | Certificate |
| ASIA | [Temporary (AWS STS) access key IDs](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) use this prefix, but are unique only in combination with the secret access key and the session token. |
| ACCA | Kontekstualni akreditiv |
| AGPA | Korisnička grupa |
| AIDA | IAM korisnik |
| AIPA | Amazon EC2 profil instance |
| AKIA | Pristupni ključ |
| ANPA | Upravljana politika |
| ANVA | Verzija u upravljanoj politici |
| APKA | Javni ključ |
| AROA | Uloga |
| ASCA | Sertifikat |
| ASIA | [Privremeni (AWS STS) pristupni ključ ID-ovi](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) koriste ovaj prefiks, ali su jedinstveni samo u kombinaciji sa tajnim pristupnim ključem i tokenom sesije. |
### Recommended permissions to audit accounts
### Preporučene dozvole za reviziju naloga
The following privileges grant various read access of metadata:
Sledeće privilegije daju različit pristup metapodacima:
- `arn:aws:iam::aws:policy/SecurityAudit`
- `arn:aws:iam::aws:policy/job-function/ViewOnlyAccess`
@@ -336,14 +326,13 @@ The following privileges grant various read access of metadata:
- `directconnect:DescribeConnections`
- `dynamodb:ListTables`
## Misc
## Razno
### CLI Authentication
In order for a regular user authenticate to AWS via CLI you need to have **local credentials**. By default you can configure them **manually** in `~/.aws/credentials` or by **running** `aws configure`.\
In that file you can have more than one profile, if **no profile** is specified using the **aws cli**, the one called **`[default]`** in that file will be used.\
Example of credentials file with more than 1 profile:
### CLI Autentifikacija
Da bi regularni korisnik autentifikovao AWS putem CLI, potrebno je imati **lokalne akreditive**. Po defaultu, možete ih konfigurisati **ručno** u `~/.aws/credentials` ili **pokretanjem** `aws configure`.\
U toj datoteci možete imati više od jednog profila, ako **nije specificiran profil** koristeći **aws cli**, koristiće se onaj nazvan **`[default]`** u toj datoteci.\
Primer datoteke akreditiva sa više od 1 profila:
```
[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
@@ -354,12 +343,10 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2
```
Ako treba da pristupite **različitim AWS nalozima** i vašem profilu je dato pravo da **pretpostavi ulogu unutar tih naloga**, ne morate ručno pozivati STS svaki put (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) i konfigurisati akreditive.
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[ **indicate which roles to assume**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), 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:
Možete koristiti `~/.aws/config` datoteku da **naznačite koje uloge da pretpostavite** i zatim koristiti `--profile` parametar kao i obično (pretpostavljanje uloge će se izvršiti na transparentan način za korisnika).\
Primer konfiguracione datoteke:
```
[profile acc2]
region=eu-west-2
@@ -368,23 +355,16 @@ role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional
```
With this config file you can then use aws cli like:
Sa ovom konfiguracionom datotekom možete koristiti aws cli kao:
```
aws --profile acc2 ...
```
Ako tražite nešto **slično** ovome, ali za **pregledač**, možete proveriti **ekstenziju** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en).
If you are looking for something **similar** to this but for the **browser** you can check the **extension** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en).
## References
## Reference
- [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
- [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/)
- [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)
{{#include ../../../banners/hacktricks-training.md}}

158
src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
View File

@@ -1,87 +1,84 @@
# AWS - Federation Abuse
# AWS - Zloupotreba federacije
{{#include ../../../banners/hacktricks-training.md}}
## SAML
For info about SAML please check:
Za informacije o SAML-u, molimo proverite:
{{#ref}}
https://book.hacktricks.xyz/pentesting-web/saml-attacks
{{#endref}}
In order to configure an **Identity Federation through SAML** you just need to provide a **name** and the **metadata XML** containing all the SAML configuration (**endpoints**, **certificate** with public key)
Da biste konfigurisali **Identitetsku federaciju putem SAML-a**, potrebno je da obezbedite **ime** i **metadata XML** koji sadrži svu SAML konfiguraciju (**endpoints**, **sertifikat** sa javnim ključem)
## OIDC - Github Actions Abuse
## OIDC - Zloupotreba Github akcija
In order to add a github action as Identity provider:
1. For _Provider type_, select **OpenID Connect**.
2. For _Provider URL_, enter `https://token.actions.githubusercontent.com`
3. Click on _Get thumbprint_ to get the thumbprint of the provider
4. For _Audience_, enter `sts.amazonaws.com`
5. Create a **new role** with the **permissions** the github action need and a **trust policy** that trust the provider like:
- ```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::0123456789:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:sub": [
"repo:ORG_OR_USER_NAME/REPOSITORY:pull_request",
"repo:ORG_OR_USER_NAME/REPOSITORY:ref:refs/heads/main"
],
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}
```
6. Note in the previous policy how only a **branch** from **repository** of an **organization** was authorized with a specific **trigger**.
7. The **ARN** of the **role** the github action is going to be able to **impersonate** is going to be the "secret" the github action needs to know, so **store** it inside a **secret** inside an **environment**.
8. Finally use a github action to configure the AWS creds to be used by the workflow:
Da biste dodali github akciju kao provajdera identiteta:
1. Za _Tip provajdera_, izaberite **OpenID Connect**.
2. Za _URL provajdera_, unesite `https://token.actions.githubusercontent.com`
3. Kliknite na _Preuzmi otisak_ da biste dobili otisak provajdera
4. Za _Publiku_, unesite `sts.amazonaws.com`
5. Kreirajte **novu ulogu** sa **dozvolama** koje github akcija zahteva i **politiku poverenja** koja veruje provajderu kao:
- ```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::0123456789:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:sub": [
"repo:ORG_OR_USER_NAME/REPOSITORY:pull_request",
"repo:ORG_OR_USER_NAME/REPOSITORY:ref:refs/heads/main"
],
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}
```
6. Obratite pažnju u prethodnoj politici kako je samo jedna **grana** iz **repozitorijuma** **organizacije** autorizovana sa specifičnim **okidačem**.
7. **ARN** uloge koju github akcija može da **imitira** biće "tajna" koju github akcija treba da zna, pa je **čuvajte** unutar **tajne** unutar **okruženja**.
8. Na kraju, koristite github akciju da konfigurišete AWS kredencijale koji će se koristiti u radnom toku:
```yaml
name: "test AWS Access"
# The workflow should only trigger on pull requests to the main branch
on:
pull_request:
branches:
- main
pull_request:
branches:
- main
# Required to get the ID Token that will be used for OIDC
permissions:
id-token: write
contents: read # needed for private repos to checkout
id-token: write
contents: read # needed for private repos to checkout
jobs:
aws:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
aws:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-region: eu-west-1
role-to-assume:${{ secrets.READ_ROLE }}
role-session-name: OIDCSession
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-region: eu-west-1
role-to-assume:${{ secrets.READ_ROLE }}
role-session-name: OIDCSession
- run: aws sts get-caller-identity
shell: bash
- run: aws sts get-caller-identity
shell: bash
```
## OIDC - EKS Abuse
## OIDC - EKS Zloupotreba
```bash
# Crate an EKS cluster (~10min)
eksctl create cluster --name demo --fargate
@@ -91,43 +88,34 @@ eksctl create cluster --name demo --fargate
# Create an Identity Provider for an EKS cluster
eksctl utils associate-iam-oidc-provider --cluster Testing --approve
```
It's possible to generate **OIDC providers** in an **EKS** cluster simply by setting the **OIDC URL** of the cluster as a **new Open ID Identity provider**. This is a common default policy:
Moguće je generisati **OIDC provajdere** u **EKS** klasteru jednostavno postavljanjem **OIDC URL-a** klastera kao **novog Open ID provajdera identiteta**. Ovo je uobičajena podrazumevana politika:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789098:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:aud": "sts.amazonaws.com"
}
}
}
]
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789098:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:aud": "sts.amazonaws.com"
}
}
}
]
}
```
Ova politika ispravno ukazuje da **samo** **EKS klaster** sa **id** `20C159CDF6F2349B68846BEC03BE031B` može preuzeti ulogu. Međutim, ne ukazuje koja usluga može preuzeti, što znači da **BILO koja usluga sa web identitet tokenom** će moći da **preuzme** ulogu.
This policy is correctly indicating than **only** the **EKS cluster** with **id** `20C159CDF6F2349B68846BEC03BE031B` can assume the role. However, it's not indicting which service account can assume it, which means that A**NY service account with a web identity token** is going to be **able to assume** the role.
In order to specify **which service account should be able to assume the role,** it's needed to specify a **condition** where the **service account name is specified**, such as:
Da bi se odredilo **koja usluga bi trebala da može da preuzme ulogu,** potrebno je odrediti **uslov** gde je **ime usluge navedeno**, kao što je:
```bash
"oidc.eks.region-code.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:sub": "system:serviceaccount:default:my-service-account",
```
## References
- [https://www.eliasbrange.dev/posts/secure-aws-deploys-from-github-actions-with-oidc/](https://www.eliasbrange.dev/posts/secure-aws-deploys-from-github-actions-with-oidc/)
{{#include ../../../banners/hacktricks-training.md}}