gitea-mirror/hacktricks-cloud

Fork 0

mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-25 04:15:49 -08:00

Files

Translator a2455dd4e6 Translated ['', 'src/pentesting-cloud/pentesting-cloud-methodology.md',

2025-09-29 22:33:16 +00:00

22 KiB

Raw Blame History

Basiese Github Inligting

Basiese Struktuur

Die basiese Github-omgewingstruktuur van 'n groot company is om 'n enterprise te besit wat verskeie organizations besit en elk van hulle kan verskeie repositories en verskeie teams bevat. Kleinere maatskappye besit moontlik net een organization en geen enterprises nie.

Vanuit 'n gebruiker se oogpunt kan 'n gebruiker 'n lid van verskillende enterprises en organizations wees. Binne hulle kan die gebruiker verskillende enterprise-, organization- en repository-rolle hê.

Boonop kan 'n gebruiker deel wees van verskillende teams met verskillende enterprise-, organization- of repository-rolle.

En uiteindelik kan repositories spesiale beskermingsmeganismes hê.

Privileges

Enterprise Roles

Enterprise owner: Mense met hierdie rol kan administrateurs bestuur, organizations binne die enterprise bestuur, enterprise-instellings bestuur, beleid oor organizations afdwing. Hulle kan egter nie toegang hê tot organization-instellings of inhoud tensy hulle 'n organization owner gemaak word of direkte toegang tot 'n deur 'n organization besit repo gegee word.
Enterprise members: Lede van organizations wat deur jou enterprise besit word, is ook outomaties lede van die enterprise.

Organization Roles

In 'n organization kan gebruikers verskillende rolle hê:

Organization owners: Organization owners het volledige administratiewe toegang tot jou organization. Hierdie rol moet beperk word, maar aan nie minder as twee mense in jou organization gegee word nie.
Organization members: Die standaard, nie-administratiewe rol vir mense in 'n organization is die organization member. Standaard het organization members 'n aantal toestemmings.
Billing managers: Billing managers is gebruikers wat die billing-instellings vir jou organization kan bestuur, soos betalingsinligting.
Security Managers: Dit is 'n rol wat organization owners aan enige span in 'n organization kan toeken. Wanneer toegepas, gee dit elke lid van die span toestemming om security alerts en instellings oor jou organization te bestuur, sowel as lees-toestemmings vir alle repositories in die organization.
As jou organization 'n security span het, kan jy die security manager-rol gebruik om lede van die span die minste toegang te gee wat hulle nodig het tot die organization.
Github App managers: Om addisionele gebruikers te laat manage GitHub Apps owned by an organization, kan 'n owner hulle GitHub App manager-permissies gee.
Outside collaborators: 'n Outside collaborator is 'n persoon wat toegang het tot een of meer organization repositories maar nie uitdruklik 'n lid van die organization is nie.

Jy kan die toestemmings van hierdie rolle vergelyk in hierdie tabel: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Members Privileges

In https://github.com/organizations/<org_name>/settings/member_privileges kan jy die toestemmings sien wat gebruikers sal hê net omdat hulle deel is van die organization.

Die instellings wat hier gekonfigureer word, dui die volgende toestemmings van lede van die organization aan:

Om admin, writer, reader of geen toestemming oor al die organization repos te wees.
Of lede private, internal of public repositories kan skep.
Of forking van repositories moontlik is.
Of dit moontlik is om outside collaborators uit te nooi.
Of public of private sites gepubliseer kan word.
Die toestemmings wat admins oor die repositories het.
Of lede nuwe teams kan skep.

Repository Roles

By verstek word repository-rolle geskep:

Read: Aanbeveel vir non-code contributors wat jou projek wil sien of bespreek.
Triage: Aanbeveel vir contributors wat issues en pull requests proaktief moet bestuur sonder write-toegang.
Write: Aanbeveel vir contributors wat aktief na jou projek push.
Maintain: Aanbeveel vir projekbestuurders wat die repository moet bestuur sonder toegang tot sensitiewe of vernietigende aksies.
Admin: Aanbeveel vir mense wat volle toegang tot die projek benodig, insluitend sensitiewe en vernietigende aksies soos security bestuur of 'n repository verwyder.

Jy kan die toestemmings van elke rol vergelyk in hierdie tabel 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

Teams

Jy kan die teams wat in 'n organization geskep is lys in https://github.com/orgs/<org_name>/teams. Let wel, om die teams te sien wat kinders van ander teams is, moet jy elke ouer-span toegaan.

Users

Die gebruikers van 'n organization kan gelys word in https://github.com/orgs/<org_name>/people.

In die inligting van elke gebruiker kan jy die teams sien waarvan die gebruiker lid is, en die repos waartoe die gebruiker toegang het.

Github Authentication

Github bied verskillende maniere om by jou rekening aan te meld en aksies namens jou uit te voer.

Web Access

Toegang tot github.com kan jy aanmeld met jou username and password (en moontlik 'n 2FA).

SSH Keys

Jy kan jou rekening met een of verskeie public keys konfigureer wat die verwante private key to perform actions on your behalf toelaat. https://github.com/settings/keys

GPG Keys

Jy kan nie die gebruiker met hierdie keys imiteer nie, maar as jy dit nie gebruik nie, kan dit moontlik wees dat jy ontdek word omdat jy commits sonder 'n handtekening stuur. Leer meer oor vigilant mode hier.

Personal Access Tokens

Jy kan personal access tokens genereer om 'n toepassing toegang tot jou rekening te gee. Wanneer jy 'n personal access token skep, moet die gebruiker die toestemmings wat die token sal hê spesifiseer. https://github.com/settings/tokens

Oauth Applications

Oauth applications mag jou vra vir toestemmings om deel van jou github-inligting te bekom of om jou te impersonate om sekere aksies uit te voer. 'n Algemene voorbeeld hiervan is die login with github knop wat jy op sekere platforms kan sien.

Jy kan jou eie Oauth applications skep in https://github.com/settings/developers
Jy kan al die Oauth applications wat toegang tot jou rekening het sien in https://github.com/settings/applications
Jy kan die scopes wat Oauth Apps kan vra sien in https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
Jy kan derdeparty-toegang van toepassings in 'n organization sien in https://github.com/organizations/<org_name>/settings/oauth_application_policy

Sommige security-aanbevelings:

'n OAuth App moet altyd optree as die geauthentiseerde GitHub user oor alle van GitHub (byvoorbeeld wanneer dit gebruikerskennisse voorsien) en slegs toegang hê tot die gespesifiseerde scopes.
'n OAuth App kan as 'n identiteitsverskaffer gebruik word deur 'n "Login with GitHub" vir die geauthentiseerde gebruiker moontlik te maak.
Moenie 'n OAuth App bou as jy wil hê jou toepassing moet optree op 'n single repository. Met die repo OAuth scope kan OAuth Apps optree op all of die geauthentiseerde gebruiker se repositories.
Moenie '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 en dan die maatskappy verlaat, sal niemand anders toegang hê nie.
Meer in here.

Github Applications

Github applications kan vra vir toestemmings om jou github-inligting te bekom of jou te impersonate om spesifieke aksies oor spesifieke bronne 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 organisation owner or have admin permissions in 'n repository wees.
Die GitHub App moet connect to a personal account or an organisation.
Jy kan jou eie Github application skep in https://github.com/settings/apps
Jy kan al die Github applications wat toegang tot jou rekening het sien in https://github.com/settings/apps/authorizations
Dit is die API Endpoints for Github Applications https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Afhangend van die permissies van die App sal dit sommige van hulle kan toegang.
Jy kan geïnstalleerde apps in 'n organization sien in https://github.com/organizations/<org_name>/settings/installations

Sommige security-aanbevelings:

'n GitHub App moet aksies onafhanklik van 'n gebruiker neem (tensy die app 'n user-to-server token gebruik). Om user-to-server access tokens veiliger te hou, kan jy access tokens gebruik wat na 8 uur verval, en 'n refresh token wat ingeruil kan word vir 'n nuwe access token. Vir meer inligting, sien "Refreshing user-to-server access tokens."
Maak seker die GitHub App integreer met spesifieke repositories.
Die GitHub App moet connect to a personal account or an organisation.
Moet nie verwag dat die GitHub App alles weet en kan doen wat 'n gebruiker kan nie.
Moenie 'n GitHub App gebruik as jy net 'n "Login with GitHub" diens nodig het nie. Maar 'n GitHub App kan 'n user identification flow gebruik om gebruikers aan te meld en ander dinge te doen.
Moet nie 'n GitHub App bou as jy slegs wil optree as 'n GitHub user 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 verifieer namens die gebruiker met 'n OAuth token wat die workflow scope insluit. Die gebruiker moet admin of write-permissie op die repository hê wat die workflow-lêer bevat. Vir meer inligting, sien "Understanding scopes for OAuth apps."
Meer in here.

Github Actions

Dit is nie 'n manier om in github te autentikeer nie, maar 'n malicious Github Action kan unauthorised access to github kry en, afhangend van die privileges wat aan die Action gegee is, verskeie verskillende aanvalle uitvoer. Sien hieronder vir meer inligting.

Git Actions

Git actions laat toe om die uitvoering van kode te outomatiseer wanneer 'n gebeurtenis plaasvind. Gewoonlik is die uitgevoerde kode op een of ander manier verwant aan die kode van die repository (byvoorbeeld om 'n docker container te bou of te kontroleer dat die PR geen geheime bevat nie).

Configuration

In https://github.com/organizations/<org_name>/settings/actions is dit moontlik om die konfigurasie van die github actions vir die organization te kontroleer.

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

Dit is ook moontlik om te konfigureer wie goedkeuring nodig het om 'n Github Action te hardloop en die toestemmings van die GITHUB_TOKEN van 'n Github Action wanneer dit uitgevoer word.

Git Secrets

Github Action benodig gewoonlik sekere geheime om met github of derdeparty-toepassings te kommunikeer. Om te voorkom dat hulle in plain-text in die repo gesit word, laat github toe om hulle as Secrets te plaas.

Hierdie secrets kan gekonfigureer word vir die repo of vir die hele organization. Dan, sodat die Action toegang tot die secret kan hê, moet jy dit verklaar soos:

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

steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

Warning

Secrets kan slegs deur die Github Actions wat hulle gedeclareer het, benader word.

Sodra dit in die repo of die organizations gekonfigureer is sal users of github hulle nie weer kan benader nie, hulle sal net in staat wees om hulle te verander.

Daarom is die enigste manier om github secrets te steel om toegang tot die masjien te kry wat die Github Action uitvoer (in daardie scenario sal jy slegs toegang hê tot die secrets wat vir die Action gedeclareer is).

Git Environments

Github laat toe om environments te skep waar jy secrets kan stoor. Dan kan jy die github action toegang gee tot die secrets binne die environment met iets soos:

jobs:
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.
Daarnaast sluit environment protections in:

Required reviewers: hou jobs wat op die environment gemik is terug totdat dit goedgekeur is. Skakel Prevent self-review aan om 'n behoorlike vier‑oog‑beginsel op die goedkeuring self af te dwing.
Deployment branches and tags: beperk watter branches/tags na die environment kan deploy. Kies by voorkeur spesifieke branches/tags en maak seker daardie takke is beskerm. Let wel: die "Protected branches only" option geld vir klassieke branch-beskermings en mag nie soos verwag werk as jy rulesets gebruik nie.
Wait timer: vertraag deployments vir 'n konfigureerbare tydperk.

Dit kan ook 'n number of required reviews stel voordat 'n action wat 'n environment gebruik executing word, of 'n time wag voordat deployments voortgaan.

Git Action Runner

A Github Action kan executed inside the github environment word of in 'n third party infrastructure uitgevoer word wat deur die gebruiker gekonfigureer is.

Verskeie organisasies sal toelaat dat Github Actions in 'n third party infrastructure loop omdat dit gewoonlik goedkoper is.

Jy kan list the self-hosted runners van 'n organisasie vind by https://github.com/organizations/<org_name>/settings/actions/runners

Die manier om te vind watter Github Actions are being executed in non-github infrastructure is om te soek na runs-on: self-hosted in die Github Action konfigurasie-yaml.

Dit is not possible to run a Github Action of an organization inside a self hosted box van 'n ander organisasie omdat a unique token is generated for the Runner wanneer dit gekonfigureer word sodat dit weet waar die runner behoort.

As die custom Github Runner is configured in a machine inside AWS or GCP byvoorbeeld, kan die Action toegang hê tot die metadata endpoint en die token van die service account steel waarmee die masjien loop.

Git Action Compromise

As alle actions (of 'n kwaadwillige action) toegelaat word, kan 'n gebruiker 'n Github action gebruik wat malicious is en die container waar dit uitgevoer word compromise.

Caution

'n malicious Github Action run kan deur die aanvaller misbruik word om:

Steel al die geheime waarna die Action toegang het

Beweeg lateraal as die Action binne 'n third party infrastructure uitgevoer word waar die SA-token wat gebruik word om die masjien te laat loop, verkrygbaar is (waarskynlik via die metadata service)

Misbruik die token wat deur die workflow gebruik word om die kode van die repo te steel waar die Action uitgevoer word of dit selfs te verander.

Branch Protections

Branch protections is ontwerp om nie gebruikers die volledige beheer oor 'n repository te gee nie. Die doel is om verskeie beskermingsmetodes in plek te hê voordat iemand in staat is om kode in 'n tak te skryf.

Die branch protections of a repository kan gevind word by https://github.com/<orgname>/<reponame>/settings/branches

Note

Dit is not possible to set a branch protection at organization level. Dus moet al hierdie reëls op elke repo afsonderlik gedeclareer word.

Verskeie beskermings kan op 'n tak toegepas word (soos op master):

Jy kan require a PR before merging (sodat jy nie direk kode oor die tak kan merge nie). As dit gekies is, kan verskeie ander beskerminge in plek wees:
Require a number of approvals. Dit is baie algemeen om 1 of 2 ekstra mense te vereis om jou PR goed te keur sodat 'n enkele gebruiker nie in staat is om kode direk te merge nie.
Dismiss approvals when new commits are pushed. Indien nie, kan 'n gebruiker legit kode goedkeur en dan kwaadwillige kode byvoeg en dit merge.
Require approval of the most recent reviewable push. Verseker dat enige nuwe commits na 'n goedkeuring (insluitend pushes deur ander medewerkers) hernude hersiening veroorsaak sodat 'n aanvaller nie post-goedkeuring veranderinge kan push en merge nie.
Require reviews from Code Owners. Ten minste 1 code owner van die repo moet die PR goedkeur (sodat "lukrake" gebruikers dit nie kan goedkeur nie).
Restrict who can dismiss pull request reviews. Jy kan mense of spanne spesifiseer wat pull request reviews mag dismiss.
Allow specified actors to bypass pull request requirements. Hierdie gebruikers sal in staat wees om vorige beperkings te omseil.
Require status checks to pass before merging. Sekere kontroles moet slaag voordat die commit gemerg kan word (soos 'n GitHub App wat SAST-resultate rapporteer). Wen: bind vereiste kontroles aan 'n spesifieke GitHub App; anders kan enige app die kontrolle via die Checks API spoofs, en baie bots aanvaar skip-direktiewe (bv., "@bot-name skip").
Require conversation resolution before merging. Alle kommentaar op die kode moet opgelos wees voordat die PR gemerg kan word.
Require signed commits. Die commits moet onderteken wees.
Require linear history. Voorkom merge commits om naicktakke gepush te word.
Include administrators. As dit nie gestel is nie, kan admins die beperkings omseil.
Restrict who can push to matching branches. Beperk wie 'n PR kan stuur.

Note

Soos jy kan sien, selfs al kry jy sommige credentials van 'n gebruiker, repos mag beskerm wees wat jou verhinder om kode na master te push byvoorbeeld om die CI/CD-pyplyn te kompromitteer.

Tag Protections

Tags (soos latest, stable) is standaard veranderlik. Om 'n vier‑oog‑vloei op tag-opdaterings af te dwing, beskerm tags en koppel beskermings deur environments en branches:

In die tag protection rule, skakel Require deployments to succeed aan en vereis 'n suksesvolle deployment na 'n beskermde environment (bv., prod).
In die beoogde environment, beperk Deployment branches and tags tot die release branch (bv., main) en konfigureer opsioneel Required reviewers met Prevent self-review.
Op die release branch, konfigureer branch protections om Require a pull request te vereis, stel approvals ≥ 1, en skakel beide Dismiss approvals when new commits are pushed en Require approval of the most recent reviewable push aan.

Hierdie ketting verhoed dat 'n enkele medewerker tags kan heretiketteer of force-publish releases deur workflow YAML te wysig, aangesien deployment gates buite workflows afgedwing word.

22 KiB Raw Blame History Unescape Escape