gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-25 12:25:13 -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:29:08 +00:00
parent 2753c75e8b
commit 396dbafaf2
245 changed files with 9878 additions and 12609 deletions
Download Patch File Download Diff File Expand all files Collapse all files

250
src/pentesting-ci-cd/github-security/basic-github-information.md
View File

@@ -1,202 +1,196 @@
# Basic Github Information
# Basiese Github Inligting
{{#include ../../banners/hacktricks-training.md}}
## Basic Structure
## Basiese Struktuur
The basic github environment structure of a big **company** is to own an **enterprise** which owns **several organizations** and each of them may contain **several repositories** and **several teams.**. Smaller companies may just **own one organization and no enterprises**.
Die basiese github omgewingstruktuur van 'n groot **maatskappy** is om 'n **onderneming** te besit wat **verskeie organisasies** besit en elkeen van hulle kan **verskeie repositories** en **verskeie span** bevat. Klein maatskappye mag net **een organisasie en geen ondernemings** besit nie.
From a user point of view a **user** can be a **member** of **different enterprises and organizations**. Within them the user may have **different enterprise, organization and repository roles**.
Vanuit 'n gebruiker se perspektief kan 'n **gebruiker** 'n **lid** van **verskillende ondernemings en organisasies** wees. Binne hulle kan die gebruiker **verskillende onderneming, organisasie en repository rolle** hê.
Moreover, a user may be **part of different teams** with different enterprise, organization or repository roles.
Boonop kan 'n gebruiker **deel wees van verskillende spanne** met verskillende onderneming, organisasie of repository rolle.
And finally **repositories may have special protection mechanisms**.
En uiteindelik kan **repositories spesiale beskermingsmeganismes** hê.
## Privileges
### Enterprise Roles
### Onderneming Rolle
- **Enterprise owner**: People with this role can **manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations**. However, they **cannot access organization settings or content** unless they are made an organization owner or given direct access to an organization-owned repository
- **Enterprise members**: Members of organizations owned by your enterprise are also **automatically members of the enterprise**.
- **Ondernemingseienaar**: Mense met hierdie rol kan **administrateurs bestuur, organisasies binne die onderneming bestuur, onderneminginstellings bestuur, beleid afdwing oor organisasies**. Hulle **kan egter nie toegang tot organisasie-instellings of inhoud** verkry tensy hulle 'n organisasie-eienaar gemaak word of direkte toegang tot 'n organisasie-besit repository gegee word nie.
- **Ondernemingslede**: Lede van organisasies wat deur jou onderneming besit word, is ook **outomaties lede van die onderneming**.
### Organization Roles
### Organisasie Rolle
In an organisation users can have different roles:
In 'n organisasie kan gebruikers verskillende rolle hê:
- **Organization owners**: Organization owners have **complete administrative access to your organization**. This role should be limited, but to no less than two people, in your organization.
- **Organization members**: The **default**, non-administrative role for **people in an organization** is the organization member. By default, organization members **have a number of permissions**.
- **Billing managers**: Billing managers are users who can **manage the billing settings for your organization**, such as payment information.
- **Security Managers**: It's a role that organization owners can assign to any team in an organization. When applied, it gives every member of the team permissions to **manage security alerts and settings across your organization, as well as read permissions for all repositories** in the organization.
- If your organization has a security team, you can use the security manager role to give members of the team the least access they need to the organization.
- **Github App managers**: To allow additional users to **manage GitHub Apps owned by an organization**, an owner can grant them GitHub App manager permissions.
- **Outside collaborators**: An outside collaborator is a person who has **access to one or more organization repositories but is not explicitly a member** of the organization.
- **Organisasie-eienaars**: Organisasie-eienaars het **volledige administratiewe toegang tot jou organisasie**. Hierdie rol moet beperk word, maar nie tot minder as twee mense in jou organisasie nie.
- **Organisasie lede**: Die **standaard**, nie-administratiewe rol vir **mense in 'n organisasie** is die organisasielid. Standaard het organisasielede **'n aantal toestemmings**.
- **Faktuurbestuurders**: Faktuurbestuurders is gebruikers wat **die faktuurinstellings vir jou organisasie kan bestuur**, soos betalingsinligting.
- **Sekuriteitsbestuurders**: Dit is 'n rol wat organisasie-eienaars aan enige span in 'n organisasie kan toewys. Wanneer toegepas, gee dit elke lid van die span toestemming om **sekuriteitswaarskuwings en instellings oor jou organisasie te bestuur, sowel as leestoestemmings vir alle repositories** in die organisasie.
- As jou organisasie 'n sekuriteitspan het, kan jy die sekuriteitsbestuurderrol gebruik om lede van die span die minste toegang te gee wat hulle nodig het tot die organisasie.
- **Github App bestuurders**: Om addisionele gebruikers toe te laat om **GitHub Apps wat deur 'n organisasie besit word te bestuur**, kan 'n eienaar hulle GitHub App bestuurder toestemmings gee.
- **Buite samewerkers**: 'n Buite samewerker is 'n persoon wat **toegang het tot een of meer organisasie repositories maar nie eksplisiet 'n lid** van die organisasie is nie.
You can **compare the permissions** of these roles in this table: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
Jy kan **die toestemmings** van hierdie rolle in hierdie tabel vergelyk: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
### Members Privileges
### Lede Privileges
In _https://github.com/organizations/\<org_name>/settings/member_privileges_ you can see the **permissions users will have just for being part of the organisation**.
In _https://github.com/organizations/\<org_name>/settings/member_privileges_ kan jy die **toestemmings wat gebruikers sal hê net omdat hulle deel van die organisasie is** sien.
The settings here configured will indicate the following permissions of members of the organisation:
Die instellings hier geconfigureer sal die volgende toestemmings van lede van die organisasie aandui:
- Be admin, writer, reader or no permission over all the organisation repos.
- If members can create private, internal or public repositories.
- If forking of repositories is possible
- If it's possible to invite outside collaborators
- If public or private sites can be published
- The permissions admins has over the repositories
- If members can create new teams
- Wees admin, skrywer, leser of geen toestemming oor al die organisasie repos.
- Of lede privaat, interne of openbare repositories kan skep.
- Of fork van repositories moontlik is.
- Of dit moontlik is om buite samewerkers uit te nooi.
- Of openbare of private webwerwe gepubliseer kan word.
- Die toestemmings wat administrateurs oor die repositories het.
- Of lede nuwe spanne kan skep.
### Repository Roles
### Repository Rolle
By default repository roles are created:
Standaard word repository rolle geskep:
- **Read**: Recommended for **non-code contributors** who want to view or discuss your project
- **Triage**: Recommended for **contributors who need to proactively manage issues and pull requests** without write access
- **Write**: Recommended for contributors who **actively push to your project**
- **Maintain**: Recommended for **project managers who need to manage the repository** without access to sensitive or destructive actions
- **Admin**: Recommended for people who need **full access to the project**, including sensitive and destructive actions like managing security or deleting a repository
- **Lees**: Aanbeveel vir **nie-kode bydraers** wat jou projek wil besigtig of bespreek.
- **Triage**: Aanbeveel vir **bydraers wat proaktief probleme en pull requests moet bestuur** sonder skryftoegang.
- **Skryf**: Aanbeveel vir bydraers wat **aktief na jou projek stoot**.
- **Onderhou**: Aanbeveel vir **projekbestuurders wat die repository moet bestuur** sonder toegang tot sensitiewe of vernietigende aksies.
- **Admin**: Aanbeveel vir mense wat **volledige toegang tot die projek** benodig, insluitend sensitiewe en vernietigende aksies soos om sekuriteit te bestuur of 'n repository te verwyder.
You can **compare the permissions** of each role in this table [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
Jy kan **die toestemmings** van elke rol in hierdie tabel vergelyk [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
You can also **create your own roles** in _https://github.com/organizations/\<org_name>/settings/roles_
Jy kan ook **jou eie rolle skep** in _https://github.com/organizations/\<org_name>/settings/roles_
### Teams
### Spanne
You can **list the teams created in an organization** in _https://github.com/orgs/\<org_name>/teams_. Note that to see the teams which are children of other teams you need to access each parent team.
Jy kan **die spanne wat in 'n organisasie geskep is lys** in _https://github.com/orgs/\<org_name>/teams_. Let daarop dat jy toegang tot die spanne wat kinders van ander spanne is, moet hê deur elke ouer span te benader.
### Users
### Gebruikers
The users of an organization can be **listed** in _https://github.com/orgs/\<org_name>/people._
Die gebruikers van 'n organisasie kan **gelys** word in _https://github.com/orgs/\<org_name>/people._
In the information of each user you can see the **teams the user is member of**, and the **repos the user has access to**.
In die inligting van elke gebruiker kan jy die **spanne waarvan die gebruiker 'n lid is**, en die **repos waartoe die gebruiker toegang het** sien.
## Github Authentication
## Github Verifikasie
Github offers different ways to authenticate to your account and perform actions on your behalf.
Github bied verskillende maniere om jou rekening te verifieer en aksies namens jou uit te voer.
### Web Access
### Webtoegang
Accessing **github.com** you can login using your **username and password** (and a **2FA potentially**).
Deur **github.com** te benader, kan jy aanmeld met jou **gebruikersnaam en wagwoord** (en 'n **2FA moontlik**).
### **SSH Keys**
### **SSH Sleutels**
You can configure your account with one or several public keys allowing the related **private key to perform actions on your behalf.** [https://github.com/settings/keys](https://github.com/settings/keys)
Jy kan jou rekening met een of verskeie publieke sleutels konfigureer wat die verwante **private sleutel toelaat om aksies namens jou uit te voer.** [https://github.com/settings/keys](https://github.com/settings/keys)
#### **GPG Keys**
#### **GPG Sleutels**
You **cannot impersonate the user with these keys** but if you don't use it it might be possible that you **get discover for sending commits without a signature**. Learn more about [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
Jy **kan nie die gebruiker met hierdie sleutels naboots nie**, maar as jy dit nie gebruik nie, kan dit moontlik wees dat jy **ontdek word vir die stuur van verbintenisse sonder 'n handtekening**. Leer meer oor [waaksaamheidsmodus hier](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
### **Personal Access Tokens**
### **Persoonlike Toegangstokens**
You can generate personal access token to **give an application access to your account**. When creating a personal access token the **user** needs to **specify** the **permissions** to **token** will have. [https://github.com/settings/tokens](https://github.com/settings/tokens)
Jy kan 'n persoonlike toegangstoken genereer om **'n toepassing toegang tot jou rekening te gee**. Wanneer jy 'n persoonlike toegangstoken skep, moet die **gebruiker** die **toestemmings** spesifiseer wat die **token** sal hê. [https://github.com/settings/tokens](https://github.com/settings/tokens)
### Oauth Applications
### Oauth Toepassings
Oauth applications may ask you for permissions **to access part of your github information or to impersonate you** to perform some actions. A common example of this functionality is the **login with github button** you might find in some platforms.
Oauth toepassings mag jou om toestemmings **te vra om 'n deel van jou github inligting te bekom of om jou na te boots** om sekere aksies uit te voer. 'n Algemene voorbeeld van hierdie funksionaliteit is die **aanmeld met github knoppie** wat jy dalk in sommige platforms vind.
- You can **create** your own **Oauth applications** in [https://github.com/settings/developers](https://github.com/settings/developers)
- You can see all the **Oauth applications that has access to your account** in [https://github.com/settings/applications](https://github.com/settings/applications)
- You can see the **scopes that Oauth Apps can ask for** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
- You can see third party access of applications in an **organization** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
- Jy kan **jou eie** **Oauth toepassings** in [https://github.com/settings/developers](https://github.com/settings/developers) skep.
- Jy kan al die **Oauth toepassings wat toegang tot jou rekening het** in [https://github.com/settings/applications](https://github.com/settings/applications) sien.
- Jy kan die **skoppe wat Oauth Apps kan vra** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) sien.
- Jy kan derdeparty toegang van toepassings in 'n **organisasie** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ sien.
Some **security recommendations**:
Sommige **sekuriteitsaanbevelings**:
- An **OAuth App** should always **act as the authenticated GitHub user across all of GitHub** (for example, when providing user notifications) and with access only to the specified scopes..
- An OAuth App can be used as an identity provider by enabling a "Login with GitHub" for the authenticated user.
- **Don't** build an **OAuth App** if you want your application to act on a **single repository**. With the `repo` OAuth scope, OAuth Apps can **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s.
- **Don't** build an OAuth App to act as an application for your **team or company**. OAuth Apps authenticate as a **single user**, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it.
- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
- 'n **OAuth App** moet altyd **optree as die geverifieerde GitHub gebruiker oor die hele GitHub** (byvoorbeeld, wanneer gebruikerskennisgewings verskaf word) en met toegang slegs tot die gespesifiseerde skoppe.
- 'n OAuth App kan as 'n identiteitsverskaffer gebruik word deur 'n "Aanmeld met GitHub" vir die geverifieerde gebruiker in te skakel.
- **Moet nie** 'n **OAuth App** bou as jy wil hê jou toepassing moet op 'n **enkele repository** optree nie. Met die `repo` OAuth skop, kan OAuth Apps **optree op \_alle**\_\*\* van die geverifieerde gebruiker se repositories\*\*.
- **Moet nie** 'n OAuth App bou om as 'n toepassing vir jou **span of maatskappy** op te tree nie. OAuth Apps verifieer as 'n **enkele gebruiker**, so as een persoon 'n OAuth App vir 'n maatskappy skep om te gebruik, en dan verlaat hulle die maatskappy, sal niemand anders toegang daartoe hê nie.
- **Meer** in [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
### Github Applications
### Github Toepassings
Github applications can ask for permissions to **access your github information or impersonate you** to perform specific actions over specific resources. In Github Apps you need to specify the repositories the app will have access to.
Github toepassings kan om toestemmings vra om **toegang tot jou github inligting te verkry of om jou na te boots** om spesifieke aksies oor spesifieke hulpbronne uit te voer. In Github Apps moet jy die repositories spesifiseer waartoe die app toegang sal hê.
- To install a GitHub App, you must be an **organisation owner or have admin permissions** in a repository.
- The GitHub App should **connect to a personal account or an organisation**.
- You can create your own Github application in [https://github.com/settings/apps](https://github.com/settings/apps)
- You can see all the **Github applications that has access to your account** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
- These are the **API Endpoints for Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Depending on the permissions of the App it will be able to access some of them
- You can see installed apps in an **organization** in _https://github.com/organizations/\<org_name>/settings/installations_
- Om 'n GitHub App te installeer, moet jy 'n **organisasie-eienaar wees of admin toestemmings** in 'n repository hê.
- Die GitHub App moet **verbinde met 'n persoonlike rekening of 'n organisasie**.
- Jy kan jou eie Github toepassing in [https://github.com/settings/apps](https://github.com/settings/apps) skep.
- Jy kan al die **Github toepassings wat toegang tot jou rekening het** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) sien.
- Dit is die **API Eindpunte vir Github Toepassings** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Afhangende van die toestemmings van die App sal dit in staat wees om sommige van hulle te benader.
- Jy kan geïnstalleerde apps in 'n **organisasie** in _https://github.com/organizations/\<org_name>/settings/installations_ sien.
Some security recommendations:
Sommige sekuriteitsaanbevelings:
- A GitHub App should **take actions independent of a user** (unless the app is using a [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). To keep user-to-server access tokens more secure, you can use access tokens that will expire after 8 hours, and a refresh token that can be exchanged for a new access token. For more information, see "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
- Make sure the GitHub App integrates with **specific repositories**.
- The GitHub App should **connect to a personal account or an organisation**.
- Don't expect the GitHub App to know and do everything a user can.
- **Don't use a GitHub App if you just need a "Login with GitHub" service**. But a GitHub App can use a [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) to log users in _and_ do other things.
- Don't build a GitHub App if you _only_ want to act as a GitHub user and do everything that user can do.
- If you are using your app with GitHub Actions and want to modify workflow files, you must authenticate on behalf of the user with an OAuth token that includes the `workflow` scope. The user must have admin or write permission to the repository that contains the workflow file. For more information, see "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
- 'n GitHub App moet **aksies onafhanklik van 'n gebruiker neem** (tenzij die app 'n [gebruiker-naar-bediener](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token gebruik). Om gebruiker-naar-bediener toegangstokens veiliger te hou, kan jy toegangstokens gebruik wat na 8 uur verval, en 'n verfrissingstoken wat vir 'n nuwe toegangstoken omgeruil kan word. Vir meer inligting, sien "[Verfrissing van gebruiker-naar-bediener toegangstokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
- Maak seker dat die GitHub App integreer met **spesifieke repositories**.
- Die GitHub App moet **verbinde met 'n persoonlike rekening of 'n organisasie**.
- Moet nie verwag dat die GitHub App alles weet en doen wat 'n gebruiker kan nie.
- **Moet nie 'n GitHub App gebruik as jy net 'n "Aanmeld met GitHub" diens nodig het nie**. Maar 'n GitHub App kan 'n [gebruiker identifikasievloei](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) gebruik om gebruikers in te teken _en_ ander dinge te doen.
- Moet nie 'n GitHub App bou as jy _net_ wil optree as 'n GitHub gebruiker en alles wil doen wat daardie gebruiker kan doen nie.
- As jy jou app met GitHub Actions gebruik en workflow lêers wil wysig, moet jy namens die gebruiker verifieer met 'n OAuth token wat die `workflow` skop insluit. Die gebruiker moet admin of skryftoestemming hê tot die repository wat die workflow lêer bevat. Vir meer inligting, sien "[Begrip van skoppe vir OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
- **Meer** in [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
### Github Actions
This **isn't a way to authenticate in github**, but a **malicious** Github Action could get **unauthorised access to github** and **depending** on the **privileges** given to the Action several **different attacks** could be done. See below for more information.
Dit **is nie 'n manier om in github te verifieer nie**, maar 'n **kwaadwillige** Github Action kan **ongemagtigde toegang tot github** verkry en **afhangende** van die **privileges** wat aan die Aksie gegee word, kan verskeie **verskillende aanvalle** uitgevoer word. Sien hieronder vir meer inligting.
## Git Actions
## Git Aksies
Git actions allows to automate the **execution of code when an event happen**. Usually the code executed is **somehow related to the code of the repository** (maybe build a docker container or check that the PR doesn't contain secrets).
Git aksies laat toe om die **uitvoering van kode te outomatiseer wanneer 'n gebeurtenis plaasvind**. Gewoonlik is die kode wat uitgevoer word **op een of ander manier verwant aan die kode van die repository** (miskien 'n docker houer bou of kyk of die PR nie geheime bevat nie).
### Configuration
### Konfigurasie
In _https://github.com/organizations/\<org_name>/settings/actions_ it's possible to check the **configuration of the github actions** for the organization.
In _https://github.com/organizations/\<org_name>/settings/actions_ is dit moontlik om die **konfigurasie van die github aksies** vir die organisasie te kontroleer.
It's possible to disallow the use of github actions completely, **allow all github actions**, or just allow certain actions.
Dit is moontlik om die gebruik van github aksies heeltemal te verbied, **alle github aksies toe te laat**, of net sekere aksies toe te laat.
It's also possible to configure **who needs approval to run a Github Action** and the **permissions of the GITHUB_TOKEN** of a Github Action when it's run.
Dit is ook moontlik om te konfigureer **wie goedkeuring nodig het om 'n Github Aksie te laat loop** en die **toestemmings van die GITHUB_TOKEN** van 'n Github Aksie wanneer dit uitgevoer word.
### Git Secrets
### Git Geheime
Github Action usually need some kind of secrets to interact with github or third party applications. To **avoid putting them in clear-text** in the repo, github allow to put them as **Secrets**.
These secrets can be configured **for the repo or for all the organization**. Then, in order for the **Action to be able to access the secret** you need to declare it like:
Github Aksie benodig gewoonlik 'n soort geheime om met github of derdeparty toepassings te kommunikeer. Om te **verhoed dat hulle in duidelike teks** in die repo geplaas word, laat github toe om hulle as **Geheime** te plaas.
Hierdie geheime kan **vir die repo of vir die hele organisasie** geconfigureer word. Dan, om die **Aksie toegang tot die geheim te gee**, moet jy dit soos volg verklaar:
```yaml
steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}
```
#### Example using Bash <a href="#example-using-bash" id="example-using-bash"></a>
#### Voorbeeld met Bash <a href="#example-using-bash" id="example-using-bash"></a>
```yaml
steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"
```
> [!WARNING]
> Secrets **can only be accessed from the Github Actions** that have them declared.
> Geheimnisse **kan slegs vanaf die Github Actions** wat hulle verklaar het, toeganklik wees.
> Once configured in the repo or the organizations **users of github won't be able to access them again**, they just will be able to **change them**.
> Sodra dit in die repo of die organisasies gekonfigureer is, **sal gebruikers van github nie weer toegang tot hulle hê nie**, hulle sal net in staat wees om **hulle te verander**.
Therefore, the **only way to steal github secrets is to be able to access the machine that is executing the Github Action** (in that scenario you will be able to access only the secrets declared for the Action).
Daarom is die **enigste manier om github geheimnisse te steel, om toegang te hê tot die masjien wat die Github Action uitvoer** (in daardie scenario sal jy slegs toegang hê tot die geheimnisse wat vir die Action verklaar is).
### Git Environments
Github allows to create **environments** where you can save **secrets**. Then, you can give the github action access to the secrets inside the environment with something like:
### Git Omgewings
Github laat toe om **omgewings** te skep waar jy **geheimnisse** kan stoor. Dan kan jy die github action toegang gee tot die geheimnisse binne die omgewing met iets soos:
```yaml
jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name
deployment:
runs-on: ubuntu-latest
environment: env_name
```
You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed.
You can configure an environment to be **accessed** by **alle takke** (default), **slegs beskermde** takke of **spesifiseer** watter takke toegang kan hê.\
Dit kan ook 'n **aantal vereiste hersienings** stel voordat **uitvoering** van 'n **aksie** met 'n **omgewing** plaasvind of **wag** vir 'n **tyd** voordat ontplooiings voortgaan.
### Git Action Runner
A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
A Github Action can be **executed inside the github environment** or can be executed in a **derdeparty-infrastruktuur** geconfigureer deur die gebruiker.
Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
Verskeie organisasies sal toelaat dat Github Actions in 'n **derdeparty-infrastruktuur** gedraai word, aangesien dit gewoonlik **goedkoper** is.
You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
@@ -214,7 +208,7 @@ If all actions (or a malicious action) are allowed a user could use a **Github a
> A **malicious Github Action** run could be **abused** by the attacker to:
>
> - **Steal all the secrets** the Action has access to
> - **Move laterally** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service)
> - **Move laterally** if the Action is executed inside a **derdeparty-infrastruktuur** waar die SA-token wat gebruik word om die masjien te laat loop, toegang kan verkry (waarskynlik via die metadata-diens)
> - **Abuse the token** used by the **workflow** to **steal the code of the repo** where the Action is executed or **even modify it**.
## Branch Protections
@@ -229,11 +223,11 @@ The **branch protections of a repository** can be found in _https://github.com/\
Different protections can be applied to a branch (like to master):
- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
- **Require status checks to pass before merging.** Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged.
- **Require signed commits**. The commits need to be signed.
@@ -253,7 +247,3 @@ Different protections can be applied to a branch (like to master):
- [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
{{#include ../../banners/hacktricks-training.md}}