gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-16 06:42:39 -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:26:13 +00:00
parent 44da2ea78f
commit 6f74ac1a76
245 changed files with 9102 additions and 11816 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1,84 +1,78 @@
# AWS - Basic Information
# AWS - Taarifa za Msingi
{{#include ../../../banners/hacktricks-training.md}}
## Organization Hierarchy
## Hierarchi ya Shirika
![](<../../../images/image (151).png>)
### Accounts
### Akaunti
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.
Katika AWS kuna **akaunti ya mzizi,** ambayo ni **konteina ya mzazi kwa akaunti zote** za **shirika** lako. Hata hivyo, huwezi kutumia akaunti hiyo kupeleka rasilimali, unaweza kuunda **akaunti nyingine ili kutenganisha miundombinu tofauti za AWS** kati yao.
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.
Hii ni ya kuvutia kutoka kwa mtazamo wa **usalama**, kwani **akaunti moja haitakuwa na uwezo wa kufikia rasilimali kutoka akaunti nyingine** (isipokuwa madaraja yameundwa mahsusi), hivyo unaweza kuunda mipaka kati ya matumizi.
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.
Kwa hiyo, kuna **aina mbili za akaunti katika shirika** (tunazungumzia akaunti za AWS na si Akaunti za Mtumiaji): akaunti moja ambayo imewekwa kama akaunti ya usimamizi, na akaunti moja au zaidi za wanachama.
- 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:
- **Akaunti ya usimamizi (akaunti ya mzizi)** ndiyo akaunti unayotumia kuunda shirika. Kutoka kwa akaunti ya usimamizi ya shirika, unaweza kufanya yafuatayo:
- 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.
- Kuunda akaunti katika shirika
- Kualika akaunti nyingine zilizopo katika shirika
- Kuondoa akaunti kutoka shirika
- Kudhibiti mialiko
- Kutumia sera kwa vitu (mizizi, OUs, au akaunti) ndani ya shirika
- Kuwezesha ujumuishaji na huduma za AWS zinazoungwa mkono ili kutoa kazi za huduma katika akaunti zote za shirika.
- Inawezekana kuingia kama mtumiaji wa mzizi kwa kutumia barua pepe na nenosiri vilivyotumika kuunda akaunti hii ya mzizi/shirika.
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).
Akaunti ya usimamizi ina **majukumu ya akaunti ya kulipa** na inawajibika kwa kulipa malipo yote yanayokusanywa na akaunti za wanachama. Huwezi kubadilisha akaunti ya usimamizi ya shirika.
- **Akaunti za wanachama** zinaunda akaunti zote nyingine katika shirika. Akaunti inaweza kuwa mwanachama wa shirika moja tu kwa wakati mmoja. Unaweza kuambatisha sera kwa akaunti ili kuweka udhibiti kwa akaunti hiyo pekee.
- Akaunti za wanachama **zinapaswa kutumia anwani halali ya barua pepe** na zinaweza kuwa na **jina**, kwa ujumla hawawezi kudhibiti bili (lakini wanaweza kupewa ufikiaji wa hiyo).
```
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
```
### **Vitengo vya Shirika**
### **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.
Akaunti zinaweza kuunganishwa katika **Vitengo vya Shirika (OU)**. Kwa njia hii, unaweza kuunda **sera** za Vitengo vya Shirika ambazo zita **wekwa kwenye akaunti zote za watoto**. Kumbuka kwamba OU inaweza kuwa na OUs zingine kama watoto.
```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**.
A **service control policy (SCP)** ni sera inayobainisha huduma na vitendo ambavyo watumiaji na majukumu wanaweza kutumia katika akaunti ambazo SCP inahusisha. SCPs ni **sawa na sera za ruhusa za IAM** isipokuwa kwamba **hazitoi ruhusa yoyote**. Badala yake, SCPs zinaelezea **ruhusa za juu zaidi** kwa shirika, kitengo cha shirika (OU), au akaunti. Unapounganisha SCP na mzizi wa shirika lako au OU, **SCP inakandamiza ruhusa za viumbe katika akaunti za wanachama**.
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).
Hii ndiyo NJIA PEKEE ambayo **hata mtumiaji wa mzizi anaweza kuzuiwa** kufanya kitu. Kwa mfano, inaweza kutumika kuzuia watumiaji wasizime CloudTrail au kufuta nakala za akiba.\
Njia pekee ya kupita hii ni kuathiri pia **akaunti ya mkuu** inayoweka mipangilio ya SCPs (akaunti ya mkuu haiwezi kuzuiwa).
> [!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.
> Kumbuka kwamba **SCPs zinakandamiza tu wakuu katika akaunti**, hivyo akaunti nyingine hazihusiki. Hii inamaanisha kuwa kuwa na SCP inayokataza `s3:GetObject` haitazuia watu **kupata mfuko wa S3 wa umma** katika akaunti yako.
SCP examples:
SCP mifano:
- Deny the root account entirely
- Only allow specific regions
- Only allow white-listed services
- Deny GuardDuty, CloudTrail, and S3 Public Block Access from
- Kataza akaunti ya mzizi kabisa
- Ruhusu tu maeneo maalum
- Ruhusu tu huduma zilizoorodheshwa
- Kataza GuardDuty, CloudTrail, na S3 Public Block Access kutoka
being disabled
kuondolewa
- Deny security/incident response roles from being deleted or
- Kataza majukumu ya usalama/mjibu wa tukio kuondolewa au
modified.
kubadilishwa.
- Deny backups from being deleted.
- Deny creating IAM users and access keys
- Kataza nakala za akiba kuondolewa.
- Kataza kuunda watumiaji wa IAM na funguo za ufikiaji
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)
Pata **mifano ya JSON** katika [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** ni **jina la kipekee** kila rasilimali ndani ya AWS ina, imeundwa kama ifuatavyo:
```
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:
- AWS Standard: `aws`
@@ -86,246 +80,240 @@ Note that there are 4 partitions in AWS but only 3 ways to call them:
- AWS US public Internet (GovCloud): `aws-us-gov`
- AWS Secret (US Classified): `aws`
## IAM - Identity and Access Management
## IAM - Usimamizi wa Utambulisho na Ufikiaji
IAM is the service that will allow you to manage **Authentication**, **Authorization** and **Access Control** inside your AWS account.
IAM ni huduma itakayokuruhusu kusimamia **Uthibitishaji**, **Idhini** na **Udhibiti wa Ufikiaji** ndani ya akaunti yako ya AWS.
- **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
- **Uthibitishaji** - Mchakato wa kufafanua utambulisho na uthibitisho wa utambulisho huo. Mchakato huu unaweza kugawanywa katika: Utambulisho na uthibitisho.
- **Idhini** - Inabainisha ni nini utambulisho unaweza kufikia ndani ya mfumo mara tu unapothibitishwa.
- **Udhibiti wa Ufikiaji** - Njia na mchakato wa jinsi ufikiaji unavyotolewa kwa rasilimali salama.
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 inaweza kufafanuliwa kwa uwezo wake wa kusimamia, kudhibiti na kuongoza mitambo ya uthibitishaji, idhini na udhibiti wa ufikiaji wa utambulisho kwa rasilimali zako ndani ya akaunti yako ya AWS.
### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
### [Mtumiaji wa mizizi ya akaunti ya AWS](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**.
Unapounda akaunti ya Amazon Web Services (AWS) kwa mara ya kwanza, unaanza na utambulisho mmoja wa kuingia ambao una **ufikiaji kamili kwa huduma zote** za AWS na rasilimali katika akaunti. Hii ni akaunti ya AWS _**mtumiaji wa mizizi**_ na inafikiwa kwa kuingia kwa kutumia **anwani ya barua pepe na nenosiri ulilotumia kuunda akaunti**.
Note that a new **admin user** will have **less permissions that the root user**.
Kumbuka kwamba mtumiaji mpya wa **admin** atakuwa na **idhini ndogo kuliko mtumiaji wa mizizi**.
From a security point of view, it's recommended to create other users and avoid using this one.
Kutoka kwa mtazamo wa usalama, inapendekezwa kuunda watumiaji wengine na kuepuka kutumia huu.
### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
### [Watumiaji wa IAM](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).
Mtumiaji wa IAM ni kiumbe ambacho unaunda katika AWS ili **wakilisha mtu au programu** inayotumia hiyo ili **kuingiliana na AWS**. Mtumiaji katika AWS unajumuisha jina na ithibati (nenosiri na funguo za ufikiaji hadi mbili).
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.
Unapounda mtumiaji wa IAM, unampa **idhini** kwa kumfanya kuwa **mwanachama wa kundi la watumiaji** ambalo lina sera za idhini zinazofaa (inapendekezwa), au kwa **kuambatanisha sera moja kwa moja** kwa mtumiaji.
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)).
Watumiaji wanaweza kuwa na **MFA iliyoanzishwa kuingia** kupitia console. Tokeni za API za watumiaji walioanzisha MFA hazilindwi na MFA. Ikiwa unataka **kudhibiti ufikiaji wa funguo za API za watumiaji kwa kutumia MFA** unahitaji kuashiria katika sera hiyo kwamba ili kutekeleza vitendo fulani MFA inahitaji kuwepo (mfano [**hapa**](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).
- **Kitambulisho cha Funguo za Ufikiaji**: 20 ya herufi kubwa za alphanumeric za nasibu kama AKHDNAPO86BSHKDIRYT
- **Kitambulisho cha funguo za siri za ufikiaji**: 40 ya herufi kubwa na ndogo za nasibu: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Haiwezekani kurejesha vitambulisho vya funguo za siri vilivyopotea).
Whenever you need to **change the Access Key** this is the process you should follow:\
&#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_
Wakati wowote unahitaji **kubadilisha Funguo za Ufikiaji** huu ndio mchakato unapaswa kufuata:\
&#xNAN;_&#x43;unda funguo mpya za ufikiaji -> Tumia funguo mpya kwenye mfumo/programu -> weka ya awali kama isiyo hai -> Jaribu na thibitisha funguo mpya za ufikiaji zinafanya kazi -> Futa funguo za zamani za ufikiaji_
### MFA - Multi Factor Authentication
### MFA - Uthibitishaji wa Vigezo Vingi
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.
Inatumika ku **unda kipengele cha ziada kwa uthibitishaji** pamoja na mbinu zako zilizopo, kama vile nenosiri, hivyo kuunda kiwango cha uthibitishaji wa vigezo vingi.\
Unaweza kutumia **programu ya bure ya virtual au kifaa halisi**. Unaweza kutumia programu kama uthibitishaji wa google bure kuanzisha MFA katika AWS.
Policies with MFA conditions can be attached to the following:
Sera zenye masharti ya MFA zinaweza kuambatanishwa na yafuatayo:
- 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**.
- Mtumiaji wa IAM au kundi
- Rasilimali kama vile ndoo ya Amazon S3, foleni ya Amazon SQS, au mada ya Amazon SNS
- Sera ya kuaminika ya jukumu la IAM ambalo linaweza kuchukuliwa na mtumiaji
Ikiwa unataka **kufikia kupitia CLI** rasilimali ambayo **inaangalia MFA** unahitaji kuita **`GetSessionToken`**. Hiyo itakupa tokeni yenye taarifa kuhusu MFA.\
Kumbuka kwamba **`AssumeRole` ithibati hazina taarifa hii**.
```bash
aws sts get-session-token --serial-number <arn_device> --token-code <code>
```
As [**imesemwa hapa**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), kuna kesi nyingi tofauti ambapo **MFA haiwezi kutumika**.
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**.
### [Makundi ya watumiaji wa IAM](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>
Kundi la [mtumiaji wa IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) ni njia ya **kuunganisha sera kwa watumiaji wengi** kwa wakati mmoja, ambayo inaweza kurahisisha usimamizi wa ruhusa za watumiaji hao. **Majukumu na makundi hayawezi kuwa sehemu ya kundi**.
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**.
Unaweza kuunganisha **sera inayotegemea utambulisho kwa kundi la mtumiaji** ili kwamba **watumiaji** wote katika kundi la mtumiaji **wapate ruhusa za sera**. **Huwezi** kutambua **kundi la mtumiaji** kama **`Principal`** katika **sera** (kama sera inayotegemea rasilimali) kwa sababu makundi yanahusiana na ruhusa, si uthibitishaji, na wakuu ni entiti za IAM zilizothibitishwa.
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.
Hapa kuna sifa muhimu za makundi ya watumiaji:
Here are some important characteristics of user groups:
- Kundi la mtumiaji **linaweza kuwa na watumiaji wengi**, na **mtumiaji** anaweza **kuwa sehemu ya makundi mengi**.
- **Makundi ya watumiaji hayawezi kuingizwa**; yanaweza kuwa na watumiaji tu, si makundi mengine ya watumiaji.
- Hakuna **kundi la mtumiaji la default ambalo linajumuisha watumiaji wote katika akaunti ya AWS**. Ikiwa unataka kuwa na kundi la mtumiaji kama hilo, lazima ulunde na kupewa kila mtumiaji mpya.
- Idadi na ukubwa wa rasilimali za IAM katika akaunti ya AWS, kama vile idadi ya makundi, na idadi ya makundi ambayo mtumiaji anaweza kuwa mwanachama, zimepangwa. Kwa maelezo zaidi, angalia [IAM na AWS STS quotas](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).
### [Majukumu ya IAM](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>
**Jukumu la IAM** ni **kama** **mtumiaji**, kwa kuwa ni **utambulisho wenye sera za ruhusa zinazotambulisha kile** kinaweza na hakiwezi kufanya katika AWS. Hata hivyo, jukumu **halina akreditif yoyote** (nenosiri au funguo za ufikiaji) zinazohusishwa nalo. Badala ya kuwa na uhusiano wa kipekee na mtu mmoja, jukumu linakusudia kuwa **linaweza kuchukuliwa na yeyote anayeihitaji (na kuwa na ruhusa za kutosha)**. **Mtumiaji wa IAM anaweza kuchukua jukumu ili kwa muda** kuchukua ruhusa tofauti kwa kazi maalum. Jukumu linaweza **kupewa** [**mtumiaji wa shirikisho**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) anayeingia kwa kutumia mtoa huduma wa utambulisho wa nje badala ya IAM.
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.
Jukumu la IAM linajumuisha **aina mbili za sera**: **sera ya kuamini**, ambayo haiwezi kuwa tupu, inayoeleza **nani anaweza kuchukua** jukumu, na **sera ya ruhusa**, ambayo haiwezi kuwa tupu, inayoeleza **nini inaweza kufikiwa**.
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**.
#### Huduma ya Usalama ya Tokeni ya AWS (STS)
#### AWS Security Token Service (STS)
Huduma ya Usalama ya Tokeni ya AWS (STS) ni huduma ya wavuti inayorahisisha **utoaji wa akreditif za muda, zenye ruhusa zilizopunguzwa**. Imeundwa mahsusi kwa:
AWS Security Token Service (STS) is a web service that facilitates the **issuance of temporary, limited-privilege credentials**. It is specifically tailored for:
### [Akreditif za muda katika 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 in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
**Akreditif za muda zinatumika hasa na majukumu ya IAM**, lakini pia kuna matumizi mengine. Unaweza kuomba akreditif za muda ambazo zina seti ya ruhusa zilizopunguzwa zaidi kuliko mtumiaji wako wa kawaida wa IAM. Hii **inaepuka** wewe **kufanya kazi ambazo haziruhusiwi** na akreditif zilizopunguzwa zaidi. Faida ya akreditif za muda ni kwamba zinakoma moja kwa moja baada ya kipindi fulani. Una udhibiti juu ya muda ambao akreditif hizo ni halali.
**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.
### Sera
### Policies
#### Ruhusa za Sera
#### Policy Permissions
Zinatumiwa kupewa ruhusa. Kuna aina 2:
Are used to assign permissions. There are 2 types:
- 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).
- Sera zinazodhibitiwa na AWS (zilizopangwa na AWS)
- Sera Zinazosimamiwa na Wateja: Zimepangwa na wewe. Unaweza kuunda sera kulingana na sera zinazodhibitiwa na AWS (ukibadilisha moja yao na kuunda yako mwenyewe), ukitumia jenereta ya sera (maoni ya GUI yanayokusaidia kutoa na kukataa ruhusa) au kuandika yako mwenyewe.
Kwa **default ufikiaji** unakataliwa, ufikiaji utawekwa ikiwa jukumu maalum limeainishwa.\
Ikiwa **"Deny" moja ipo, itazidi "Allow"**, isipokuwa kwa maombi yanayotumia akreditif za usalama za mizizi ya akaunti ya AWS (ambazo zinaruhusiwa kwa default).
```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 [sehemu za kimataifa ambazo zinaweza kutumika kwa masharti katika huduma yoyote zimeandikwa hapa](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
[Sehemu maalum ambazo zinaweza kutumika kwa masharti kwa kila huduma zimeandikwa hapa](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
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).
#### Sera za Ndani
#### Inline Policies
Aina hii ya sera ni **zinazopewa moja kwa moja** kwa mtumiaji, kundi au jukumu. Hivyo, hazionekani katika orodha ya Sera kama wengine wanaweza kuzitumia.\
Sera za ndani ni muhimu ikiwa unataka **kuhifadhi uhusiano mkali wa moja kwa moja kati ya sera na kitambulisho** ambacho kimewekwa. Kwa mfano, unataka kuwa na uhakika kwamba ruhusa katika sera hazitapewa kwa bahati mbaya kwa kitambulisho kingine isipokuwa kile ambacho zimekusudiwa. Unapokuwa unatumia sera ya ndani, ruhusa katika sera hiyo haziwezi kuunganishwa kwa bahati mbaya na kitambulisho kibaya. Zaidi ya hayo, unapokuwa unatumia AWS Management Console kufuta kitambulisho hicho, sera zilizoingizwa katika kitambulisho pia zitatolewa. Hiyo ni kwa sababu ni sehemu ya chombo kikuu.
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.
#### Sera za Rasilimali za Ndoo
#### Resource Bucket Policies
Hizi ni **sera** ambazo zinaweza kufafanuliwa katika **rasilimali**. **Sio rasilimali zote za AWS zinazozipokea**.
These are **policies** that can be defined in **resources**. **Not all resources of AWS supports them**.
Ikiwa chombo hakina kukataa waziwazi juu yao, na sera ya rasilimali inawapa ufikiaji, basi wanaruhusiwa.
If a principal does not have an explicit deny on them, and a resource policy grants them access, then they are allowed.
### Mipaka ya IAM
### IAM Boundaries
Mipaka ya IAM inaweza kutumika **kudhibiti ruhusa ambazo mtumiaji au jukumu linapaswa kuwa na ufikiaji**. Kwa njia hii, hata kama seti tofauti za ruhusa zinatolewa kwa mtumiaji na **sera tofauti**, operesheni itashindwa ikiwa atajaribu kuzitumia.
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.
Mpaka ni sera tu iliyoambatanishwa na mtumiaji ambayo **inaonyesha kiwango cha juu cha ruhusa ambacho mtumiaji au jukumu linaweza kuwa nacho**. Hivyo, **hata kama mtumiaji ana ufikiaji wa Msimamizi**, ikiwa mpaka inaonyesha anaweza kusoma tu ndoo za S·, hiyo ndiyo kiwango cha juu anachoweza kufanya.
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.
**Hii**, **SCPs** na **kufuata kanuni ya ruhusa ndogo** ndiyo njia za kudhibiti kwamba watumiaji hawana ruhusa zaidi ya zile anazohitaji.
**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.
### Sera za Kikao
### 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.
Sera ya kikao ni **sera inayowekwa wakati jukumu linachukuliwa** kwa namna fulani. Hii itakuwa kama **mpaka wa IAM kwa kikao hicho**: Hii inamaanisha kwamba sera ya kikao haitoi ruhusa bali **inaweka vizuizi kwa zile zilizoonyeshwa katika sera** (ikiwa ruhusa za juu ni zile ambazo jukumu lina).
Hii ni muhimu kwa **hatua za usalama**: Wakati msimamizi anapokuwa anachukua jukumu lenye mamlaka makubwa anaweza kupunguza ruhusa kuwa zile tu zilizoonyeshwa katika sera ya kikao endapo kikao kitakumbwa na hatari.
```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>]
```
Note that by default **AWS inaweza kuongeza sera za kikao kwa vikao** ambavyo vitaundwa kwa sababu za tatu. Kwa mfano, katika [roles za cognito zisizo na uthibitisho](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) kwa kawaida (kwa kutumia uthibitisho ulioimarishwa), AWS itaunda **akiba za kikao zenye sera ya kikao** ambayo inakadiria huduma ambazo kikao kinaweza kufikia [**katika orodha ifuatayo**](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).
Hivyo, ikiwa kwa wakati fulani unakutana na kosa "... kwa sababu hakuna sera ya kikao inayoruhusu ...", na jukumu lina ufikiaji wa kutekeleza kitendo hicho, ni kwa sababu **kuna sera ya kikao inayozuia**.
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**.
### Ushirikiano wa Utambulisho
### Identity Federation
Ushirikiano wa utambulisho **unawaruhusu watumiaji kutoka kwa watoa huduma za utambulisho ambao ni nje** ya AWS kufikia rasilimali za AWS kwa usalama bila ya kutoa akiba za mtumiaji wa AWS kutoka kwa akaunti halali ya IAM.\
Mfano wa mtoa huduma wa utambulisho unaweza kuwa **Microsoft Active Directory** yako mwenyewe (kupitia **SAML**) au huduma za **OpenID** (kama **Google**). Ufikiaji wa ushirikiano utaweza kuruhusu watumiaji ndani yake kufikia AWS.
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.
Ili kuunda uaminifu huu, **Mtoa Huduma wa Utambulisho wa IAM unaundwa (SAML au OAuth)** ambao utakuwa **na uaminifu** kwa **jukwaa lingine**. Kisha, angalau **jukumu moja linapewa (linaloaminika) kwa Mtoa Huduma wa Utambulisho**. Ikiwa mtumiaji kutoka kwenye jukwaa lililoaminika anafikia AWS, atakuwa akifikia kama jukumu lililotajwa.
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.
Hata hivyo, kwa kawaida unataka kutoa **jukumu tofauti kulingana na kundi la mtumiaji** katika jukwaa la upande wa tatu. Kisha, **majukumu kadhaa ya IAM yanaweza kuamini** Mtoa Huduma wa Utambulisho wa upande wa tatu na jukwaa la upande wa tatu litakuwa lile linaloruhusu watumiaji kuchukua jukumu moja au jingine.
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
### IAM Identity Center
### Kituo cha Utambulisho wa IAM
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.
Kituo cha Utambulisho wa AWS IAM (mfuasi wa AWS Single Sign-On) kinapanua uwezo wa Usimamizi wa Utambulisho na Ufikiaji wa AWS (IAM) kutoa **mahali pa kati** ambalo linaunganisha **usimamizi wa watumiaji na ufikiaji wao kwa akaunti za AWS** na programu za wingu.
The login domain is going to be something like `<user_input>.awsapps.com`.
Domeni la kuingia litakuwa kitu kama `<user_input>.awsapps.com`.
To login users, there are 3 identity sources that can be used:
Ili kuingia watumiaji, kuna vyanzo 3 vya utambulisho ambavyo vinaweza kutumika:
- 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)
- Kituo cha Utambulisho: Watumiaji wa kawaida wa AWS
- Active Directory: Inasaidia viunganishi tofauti
- Mtoa Huduma wa Utambulisho wa Nje: Watumiaji wote na makundi yanatoka kwa Mtoa Huduma wa Utambulisho wa Nje (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.
Katika kesi rahisi ya kituo cha utambulisho, **Kituo cha Utambulisho kitakuwa na orodha ya watumiaji na makundi** na kitakuwa na uwezo wa **kutoa sera** kwao kwa **akaunti yoyote** ya shirika.
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.
Ili kutoa ufikiaji kwa mtumiaji/kundi wa Kituo cha Utambulisho kwa akaunti, **Mtoa Huduma wa Utambulisho wa SAML unaoaminika Kituo cha Utambulisho utaundwa**, na **jukumu linaloaminika Mtoa Huduma wa Utambulisho lenye sera zilizotajwa litaundwa** katika akaunti ya marudio.
#### 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`**.
Inawezekana **kutoa ruhusa kupitia sera za ndani kwa majukumu yaliyoandaliwa kupitia Kituo cha Utambulisho wa IAM**. Majukumu yaliyoandaliwa katika akaunti zinazotolewa **sera za ndani katika Kituo cha Utambulisho wa AWS** yatakuwa na ruhusa hizi katika sera ya ndani inayoitwa **`AwsSSOInlinePolicy`**.
Therefore, even if you see 2 roles with an inline policy called **`AwsSSOInlinePolicy`**, it **doesn't mean it has the same permissions**.
Hivyo, hata kama unaona majukumu 2 yenye sera ya ndani inayoitwa **`AwsSSOInlinePolicy`**, **haimaanishi ina ruhusa sawa**.
### Cross Account Trusts and Roles
### Uaminifu na Majukumu ya Akaunti Mbalimbali
**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.
**Mtumiaji** (anayeaminika) anaweza kuunda Jukumu la Akaunti Mbalimbali lenye sera fulani na kisha, **kuruhusu mtumiaji mwingine** (aliyeaminika) **kuingia kwenye akaunti yake** lakini tu **akiwa na ufikiaji ulioainishwa katika sera mpya za jukumu**. Ili kuunda hii, tengeneza Jukumu jipya na uchague Jukumu la Akaunti Mbalimbali. Majukumu ya Ufikiaji wa Akaunti Mbalimbali yanatoa chaguzi mbili. Kutoa ufikiaji kati ya akaunti za AWS ambazo unamiliki, na kutoa ufikiaji kati ya akaunti ambayo unamiliki na akaunti ya AWS ya upande wa tatu.\
Inapendekezwa **kueleza mtumiaji ambaye anaaminika na si kuweka kitu chochote cha jumla** kwa sababu vinginevyo, watumiaji wengine walioidhinishwa kama watumiaji wa ushirikiano wataweza pia kutumia uaminifu huu.
### AWS Simple AD
Not supported:
Haitambuliwi:
- 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
- Mahusiano ya Uaminifu
- Kituo cha Usimamizi wa AD
- Msaada kamili wa PS API
- Kituo cha Recycle cha AD
- Akaunti za Huduma za Kundi
- Upanuzi wa Schema
- Hakuna ufikiaji wa moja kwa moja kwa OS au Mifano
#### Web Federation or OpenID Authentication
#### Ushirikiano wa Mtandao au Uthibitishaji wa OpenID
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.
Programu inatumia AssumeRoleWithWebIdentity kuunda akiba za muda. Hata hivyo, hii haitoi ufikiaji kwa console ya AWS, bali ufikiaji tu kwa rasilimali ndani ya AWS.
### Other IAM options
### Chaguzi Nyingine za IAM
- 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**.
- Unaweza **kufafanua mipangilio ya sera ya nywila** kama urefu wa chini na mahitaji ya nywila.
- Unaweza **kupakua "Ripoti ya Akiba"** yenye taarifa kuhusu akiba za sasa (kama wakati wa kuunda mtumiaji, ikiwa nywila imewekwa...). Unaweza kuunda ripoti ya akiba mara kwa mara kama mara moja kila **saa nne**.
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**.
Usimamizi wa Utambulisho na Ufikiaji wa AWS (IAM) unatoa **udhibiti wa ufikiaji wa kina** katika AWS yote. Kwa IAM, unaweza kufafanua **nani anaweza kufikia huduma na rasilimali zipi**, na chini ya hali zipi. Kwa sera za IAM, unasimamia ruhusa kwa wafanyakazi na mifumo yako ili **kuhakikisha ruhusa za chini zaidi**.
### IAM ID Prefixes
### Awali za ID za IAM
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:
Katika [**ukurasa huu**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) unaweza kupata **awali za ID za IAM** za funguo kulingana na asili yao:
| ABIA | [AWS STS service bearer token](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| ABIA | [Token ya mtoa huduma ya AWS STS](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 | Akiba maalum ya muktadha |
| AGPA | Kundi la mtumiaji |
| AIDA | Mtumiaji wa IAM |
| AIPA | Profaili ya mfano wa Amazon EC2 |
| AKIA | Funguo ya ufikiaji |
| ANPA | Sera iliyosimamiwa |
| ANVA | Toleo katika sera iliyosimamiwa |
| APKA | Funguo ya umma |
| AROA | Jukumu |
| ASCA | Cheti |
| ASIA | [Funguo za ufikiaji za muda (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) tumia awali hii, lakini ni za kipekee tu kwa pamoja na funguo ya siri ya ufikiaji na tokeni ya kikao. |
### Recommended permissions to audit accounts
### Ruhusa zinazopendekezwa kukagua akaunti
The following privileges grant various read access of metadata:
Ruhusa zifuatazo zinatoa ufikiaji wa kusoma wa metadata:
- `arn:aws:iam::aws:policy/SecurityAudit`
- `arn:aws:iam::aws:policy/job-function/ViewOnlyAccess`
@@ -336,14 +324,13 @@ The following privileges grant various read access of metadata:
- `directconnect:DescribeConnections`
- `dynamodb:ListTables`
## Misc
## Mambo Mengine
### 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:
### Uthibitishaji wa CLI
Ili mtumiaji wa kawaida aidhinishe kwa AWS kupitia CLI unahitaji kuwa na **akiba za ndani**. Kwa kawaida unaweza kuziunda **kwa mikono** katika `~/.aws/credentials` au kwa **kukimbia** `aws configure`.\
Katika faili hiyo unaweza kuwa na zaidi ya profaili moja, ikiwa **hakuna profaili** iliyotajwa kwa kutumia **aws cli**, ile inayoitwa **`[default]`** katika faili hiyo itatumika.\
Mfano wa faili la akiba lenye zaidi ya profaili 1:
```
[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
@@ -354,12 +341,10 @@ 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[ **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:
Mfano wa faili la usanidi:
```
[profile acc2]
region=eu-west-2
@@ -368,23 +353,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:
Na faili hii ya usanidi unaweza kutumia aws cli kama:
```
aws --profile acc2 ...
```
Ikiwa unatafuta kitu **kama** hiki lakini kwa **browser** unaweza kuangalia **extension** [**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
## Marejeleo
- [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}}

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

@@ -4,84 +4,81 @@
## SAML
For info about SAML please check:
Kwa maelezo kuhusu SAML tafadhali angalia:
{{#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)
Ili kuunda **Utambulisho wa Shirikisho kupitia SAML** unahitaji tu kutoa **jina** na **metadata XML** inayojumuisha usanidi wote wa SAML (**mipaka**, **cheti** chenye funguo za umma)
## OIDC - Github Actions Abuse
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:
Ili kuongeza hatua ya github kama Mtoa Utambulisho:
1. Kwa _Aina ya Mtoa_, chagua **OpenID Connect**.
2. Kwa _URL ya Mtoa_, ingiza `https://token.actions.githubusercontent.com`
3. Bonyeza _Pata thumbprint_ ili kupata thumbprint ya mtoa
4. Kwa _Watazamaji_, ingiza `sts.amazonaws.com`
5. Unda **jukumu jipya** lenye **idhini** zinazohitajika na hatua ya github na **sera ya kuamini** inayomwamini mtoa kama:
- ```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. Kumbuka katika sera iliyopita jinsi tu **tawi** kutoka **hifadhi** ya **shirika** lilihitajika kwa **kichocheo** maalum.
7. **ARN** ya **jukumu** ambalo hatua ya github itakuwa na uwezo wa **kujifanya** itakuwa "siri" ambayo hatua ya github inahitaji kujua, hivyo **hifadhi** ndani ya **siri** ndani ya **mazingira**.
8. Hatimaye tumia hatua ya github kuunda AWS creds zitakazotumika na mchakato:
```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 Dhulumu
```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:
Ni rahisi kuunda **OIDC providers** katika **EKS** cluster kwa kuweka **OIDC URL** ya cluster kama **mtoa kitambulisho kipya cha Open ID**. Hii ni sera ya kawaida ya default:
```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"
}
}
}
]
}
```
Hii sera inadhihirisha kwa usahihi kwamba **tu** **EKS cluster** yenye **id** `20C159CDF6F2349B68846BEC03BE031B` inaweza kuchukua jukumu. Hata hivyo, haionyeshi ni akaunti gani ya huduma inaweza kuchukua jukumu hilo, ambayo inamaanisha kwamba **AKAUNTI YOYOTE YA HUDUMA yenye tokeni ya utambulisho wa wavuti** itakuwa **na uwezo wa kuchukua** jukumu hilo.
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:
Ili kubainisha **ni akaunti gani ya huduma inapaswa kuwa na uwezo wa kuchukua jukumu,** inahitajika kubainisha **hali** ambapo **jina la akaunti ya huduma limebainishwa**, kama:
```bash
"oidc.eks.region-code.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:sub": "system:serviceaccount:default:my-service-account",
```
## References
## Marejeleo
- [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}}