# Basiese Github Inligting

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

## Basiese Struktuur

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.

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ê.

Boonop kan 'n gebruiker **deel wees van verskillende spanne** met verskillende onderneming, organisasie of repository rolle.

En uiteindelik kan **repositories spesiale beskermingsmeganismes** hê.

## Privileges

### Onderneming Rolle

- **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.
- **Ondernemingslede**: Lede van organisasies wat deur jou onderneming besit word, is ook **outomaties lede van die onderneming**.

### Organisasie Rolle

In 'n organisasie kan gebruikers verskillende rolle hê:

- **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.
- **Buitelandse samewerkers**: 'n Buitelandse samewerker is 'n persoon wat **toegang het tot een of meer organisasie repositories maar nie eksplisiet 'n lid** van die organisasie is.

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)

### Lede Privileges

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.

Die instellings hier geconfigureer sal die volgende toestemmings van lede van die organisasie aandui:

- 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 buitelandse 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 Rolle

Standaard word repository rolle geskep:

- **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.

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)

Jy kan ook **jou eie rolle skep** in _https://github.com/organizations/\<org_name>/settings/roles_

### Spanne

Jy kan **die spanne wat in 'n organisasie geskep is lys** in _https://github.com/orgs/\<org_name>/teams_. Let daarop dat jy om die spanne wat kinders van ander spanne is te sien, elke ouer span moet toegang.

### Gebruikers

Die gebruikers van 'n organisasie kan **gelys** word in _https://github.com/orgs/\<org_name>/people._

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 Verifikasie

Github bied verskillende maniere om jou rekening te verifieer en aksies namens jou uit te voer.

### Webtoegang

Deur **github.com** te benader kan jy aanmeld met jou **gebruikersnaam en wagwoord** (en 'n **2FA moontlik**).

### **SSH Sleutels**

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 Sleutels**

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).

### **Persoonlike Toegangstokens**

Jy kan 'n persoonlike toegangstoken genereer om **'n toepassing toegang tot jou rekening te gee**. Wanneer 'n persoonlike toegangstoken geskep word, moet die **gebruiker** die **toestemmings** spesifiseer wat die **token** sal hê. [https://github.com/settings/tokens](https://github.com/settings/tokens)

### Oauth Toepassings

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.

- 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.

Sommige **sekuriteitsaanbevelings**:

- '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 die maatskappy verlaat, sal niemand anders toegang hê nie.
- **Meer** in [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).

### Github Toepassings

Github toepassings kan om toestemmings te vra om **toegang tot jou github inligting 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ê.

- 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.

Sommige sekuriteitsaanbevelings:

- '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 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 log en ander dinge te doen.
- Moet nie 'n GitHub App bou as jy _net_ wil optree as 'n GitHub gebruiker en alles 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 skryf toestemming 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

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 Action gegee word, kan verskeie **verskillende aanvalle** uitgevoer word. Sien hieronder vir meer inligting.

## Git Aksies

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).

### Konfigurasie

In _https://github.com/organizations/\<org_name>/settings/actions_ is dit moontlik om die **konfigurasie van die github actions** vir die organisasie te kontroleer.

Dit is moontlik om die gebruik van github actions heeltemal te verbied, **alle github actions toe te laat**, of net sekere aksies toe te laat.

Dit is ook moontlik om te konfigureer **wie goedkeuring benodig om 'n Github Action te laat loop** en die **toestemmings van die GITHUB_TOKEN** van 'n Github Action wanneer dit uitgevoer word.

### Git Geheimen

Github Action benodig gewoonlik 'n soort geheim 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 **Action 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 }}
```
#### 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"
```
> [!WARNING]
> Geheime **kan slegs vanaf die Github Actions** wat dit verklaar, toegang verkry.

> Sodra dit in die repo of die organisasies geconfigureer is, **sal gebruikers van github nie weer toegang tot hulle hê nie**, hulle sal net in staat wees om **hulle te verander**.

Daarom is die **enige manier om github geheime te steel, om toegang te hê tot die masjien wat die Github Action uitvoer** (in daardie scenario sal jy slegs toegang hê tot die geheime wat vir die Action verklaar is).

### Git Omgewings

Github laat toe om **omgewings** te skep waar jy **geheime** kan stoor. Dan kan jy die github action toegang gee tot die geheime binne die omgewing met iets soos:
```yaml
jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name
```
U kan 'n omgewing konfigureer om **toegang** te hê tot **alle takke** (standaard), **slegs beskermde** takke of **spesifiseer** watter takke toegang kan hê.\
Dit kan ook 'n **aantal vereiste hersienings** stel voordat 'n **aksie** met 'n **omgewing** uitgevoer word of **wag** 'n **tyd** voordat ontplooiings voortgaan.

### Git Action Runner

'n Github Aksie kan **binne die github omgewing uitgevoer word** of kan uitgevoer word in 'n **derdeparty-infrastruktuur** wat deur die gebruiker gekonfigureer is.

Verskeie organisasies sal toelaat dat Github Aksies in 'n **derdeparty-infrastruktuur** uitgevoer word, aangesien dit gewoonlik **goedkoper** is.

U kan die **self-gehoste runners** van 'n organisasie lys in _https://github.com/organizations/\<org_name>/settings/actions/runners_

Die manier om te vind watter **Github Aksies in nie-github infrastruktuur uitgevoer word** is om te soek na `runs-on: self-hosted` in die Github Aksie konfigurasie yaml.

Dit is **nie moontlik om 'n Github Aksie van 'n organisasie binne 'n self-gehoste boks** van 'n ander organisasie uit te voer nie, omdat **'n unieke token vir die Runner gegenereer word** wanneer dit gekonfigureer word om te weet waar die runner behoort.

As die persoonlike **Github Runner in 'n masjien binne AWS of GCP** gekonfigureer is, kan die Aksie **toegang hê tot die metadata-eindpunt** en **die token van die diensrekening** wat die masjien gebruik, **steel**.

### Git Action Compromise

As alle aksies (of 'n kwaadwillige aksie) toegelaat word, kan 'n gebruiker 'n **Github aksie** gebruik wat **kwaadwillig** is en die **houer** waar dit uitgevoer word, **kompromitteer**.

> [!CAUTION]
> 'n **Kwaadwillige Github Aksie** kan **misbruik** word deur die aanvaller om:
>
> - **Al die geheime** wat die Aksie toegang het, te **steel**
> - **Lateraal te beweeg** as die Aksie binne 'n **derdeparty-infrastruktuur** uitgevoer word waar die SA-token wat gebruik word om die masjien te laat loop, toegang kan verkry (waarskynlik via die metadata-diens)
> - **Die token** wat deur die **werkvloei** gebruik word, te **misbruik** om die kode van die repo waar die Aksie uitgevoer word, te **steel** of **selfs dit te wysig**.

## Takbeskermings

Takbeskermings is ontwerp om **nie volledige beheer oor 'n repo** aan die gebruikers te gee nie. Die doel is om **verskeie beskermingsmetodes te plaas voordat daar geskryf kan word in 'n sekere tak**.

Die **takbeskermings van 'n repo** kan gevind word in _https://github.com/\<orgname>/\<reponame>/settings/branches_

> [!NOTE]
> Dit is **nie moontlik om 'n takbeskerming op organisasievlak in te stel** nie. So, al hierdie moet op elke repo verklaar word.

Verskillende beskermings kan op 'n tak toegepas word (soos op meester):

- U kan **'n PR vereis voordat dit saamgevoeg word** (so u kan nie direk kode oor die tak saamvoeg nie). As dit gekies word, kan verskillende ander beskermings in plek wees:
- **Vereis 'n aantal goedkeuringe**. Dit is baie algemeen om 1 of 2 meer mense te vereis om u PR goed te keur sodat 'n enkele gebruiker nie in staat is om kode direk saam te voeg nie.
- **Verwerp goedkeuringe wanneer nuwe verbintenisse gestuur word**. As nie, kan 'n gebruiker wettige kode goedkeur en dan kan die gebruiker kwaadwillige kode byvoeg en dit saamvoeg.
- **Vereis hersienings van Kode-eienaars**. Ten minste 1 kode-eienaar van die repo moet die PR goedkeur (sodat "ewekansige" gebruikers dit nie kan goedkeur nie)
- **Beperk wie kan pull request hersienings verwerp.** U kan mense of spanne spesifiseer wat toegelaat word om pull request hersienings te verwerp.
- **Laat gespesifiseerde akteurs toe om pull request vereistes te omseil**. Hierdie gebruikers sal in staat wees om vorige beperkings te omseil.
- **Vereis status kontroles om te slaag voordat dit saamgevoeg word.** Sommige kontroles moet slaag voordat die verbintenis saamgevoeg kan word (soos 'n github aksie wat kyk of daar nie enige duidelike teks geheim is nie).
- **Vereis gesprekresolusie voordat dit saamgevoeg word**. Alle kommentaar op die kode moet opgelos word voordat die PR saamgevoeg kan word.
- **Vereis geskrewe verbintenisse**. Die verbintenisse moet geskrewe wees.
- **Vereis lineêre geskiedenis.** Voorkom dat saamvoegverbintenisse na ooreenstemmende takke gestuur word.
- **Sluit administrateurs in**. As dit nie ingestel is nie, kan administrateurs die beperkings omseil.
- **Beperk wie kan na ooreenstemmende takke druk**. Beperk wie 'n PR kan stuur.

> [!NOTE]
> Soos u kan sien, selfs al het u daarin geslaag om 'n paar akrediteerbare inligting van 'n gebruiker te verkry, **kan repos beskerm word wat u verhoed om kode na meester te druk** om byvoorbeeld die CI/CD-pyplyn te kompromitteer.

## Verwysings

- [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
- [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
- [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github)
- [https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards)
- [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}}