# बुनियादी Github जानकारी

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

## बुनियादी संरचना

एक बड़े **company** के लिए बुनियादी github वातावरण की संरचना यह है कि उसके पास एक **enterprise** होता है जो कई **organizations** का मालिक होता है और हर एक में कई **repositories** और कई **teams** हो सकते हैं। छोटी कंपनियों के पास केवल **एक organization और कोई enterprise नहीं** भी हो सकता है।

किसी user के दृष्टिकोण से एक **user** अलग-अलग **enterprises और organizations** का **member** हो सकता है। इनके भीतर user के पास **विभिन्न enterprise, organization और repository रोल्स** हो सकते हैं।

इसके अलावा, एक user अलग-अलग **teams** का हिस्सा हो सकता है जिनमें अलग-अलग enterprise, organization या repository रोल्स होते हैं।

और अंत में **repositories में विशेष protection mechanisms हो सकते हैं।**

## Privileges

### Enterprise Roles

- **Enterprise owner**: इस रोल वाले लोग **administrators को manage कर सकते हैं, enterprise के भीतर organizations को manage कर सकते हैं, enterprise settings को manage कर सकते हैं, और organizations पर policy लागू कर सकते हैं।** हालांकि, वे **organization settings या content तक पहुँच नहीं बना सकते** जब तक उन्हें organization owner बनाया न गया हो या सीधे organization-owned repository का access न दिया गया हो।
- **Enterprise members**: आपके enterprise द्वारा owned organizations के members स्वचालित रूप से **enterprise के members** भी होते हैं।

### Organization Roles

एक organisation में users के अलग-अलग रोल हो सकते हैं:

- **Organization owners**: Organization owners के पास **आपकी organization पर पूर्ण administrative access** होता है। यह रोल सीमित रखा जाना चाहिए, लेकिन आपकी organization में कम से कम दो लोगों से कम नहीं होना चाहिए।
- **Organization members**: organization में लोगों के लिए डिफ़ॉल्ट, non-administrative रोल organization member है। डिफ़ॉल्ट के रूप में, organization members **कई permissions** रखते हैं।
- **Billing managers**: Billing managers वे users होते हैं जो आपकी organization के billing settings, जैसे payment information, **manage कर सकते हैं**।
- **Security Managers**: यह एक रोल है जिसे organization owners किसी भी टीम को दे सकते हैं। लागू होने पर, यह टीम के हर सदस्य को **organization भर में security alerts और settings manage करने की permissions देता है, साथ ही organization के सभी repositories के लिए read permissions** देता है।
- यदि आपकी organization में एक security team है, तो आप security manager रोल का उपयोग टीम के सदस्यों को organization तक न्यूनतम आवश्यक access देने के लिए कर सकते हैं।
- **Github App managers**: किसी organization द्वारा owned GitHub Apps को अतिरिक्त users को **manage करने के लिए** अनुमति देने के लिए, एक owner उन्हें GitHub App manager permissions दे सकता है।
- **Outside collaborators**: Outside collaborator वह व्यक्ति होता है जिसे **एक या अधिक organization repositories तक पहुँचन है पर वह organization का स्पष्ट रूप से member नहीं है।**

आप इन रोल्स की permissions की तुलना इस तालिका में कर सकते हैं: [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

_in_ https://github.com/organizations/\<org_name>/settings/member_privileges आप देख सकते हैं कि **organization का हिस्सा होने के नाते users को कौन-कौन सी permissions मिलेंगी**।

यहाँ configured settings organization के members की निम्नलिखित permissions को संकेत करेंगी:

- organization के सभी repos पर admin, writer, reader या कोई permission नहीं होना।
- क्या members private, internal या public repositories बना सकते हैं।
- क्या repositories का forking संभव है।
- क्या outside collaborators को invite करना संभव है।
- क्या public या private sites publish की जा सकती हैं।
- repositories पर admins के पास क्या permissions हैं।
- क्या members नई teams बना सकते हैं।

### Repository Roles

डिफ़ॉल्ट रूप से repository रोल्स बनाये जाते हैं:

- **Read**: उन **non-code contributors** के लिए अनुशंसित जो आपका प्रोजेक्ट देखना या उस पर चर्चा करना चाहते हैं।
- **Triage**: उन contributors के लिए अनुशंसित जो issues और pull requests को proactively manage करने की ज़रूरत रखते हैं बिना write access के।
- **Write**: उन contributors के लिए अनुशंसित जो **actively आपके प्रोजेक्ट में push करते हैं**।
- **Maintain**: उन project managers के लिए अनुशंसित जो repository को manage करने की ज़रूरत रखते हैं बिना संवेदनशील या destructive क्रियाओं के access के।
- **Admin**: उन लोगों के लिए अनुशंसित जिन्हें प्रोजेक्ट पर **पूर्ण access** चाहिए, जिसमें security manage करना या repository delete करना जैसी संवेदनशील और destructive क्रियाएँ शामिल हैं।

आप प्रत्येक रोल की permissions की तुलना इस तालिका में कर सकते हैं [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)

आप अपने खुद के roles भी बना सकते हैं _https://github.com/organizations/\<org_name>/settings/roles_

### Teams

आप किसी organization में बनाए गए teams की सूची _https://github.com/orgs/\<org_name>/teams_ पर देख सकते हैं। ध्यान दें कि किसी team के child teams देखने के लिए आपको प्रत्येक parent team तक पहुँचना होगा।

### Users

Organization के users _https://github.com/orgs/\<org_name>/people_ में **listed** हो सकते हैं।

प्रत्येक user की जानकारी में आप देख सकते हैं कि user किस **teams** का member है, और user को कौन-कौन से **repos** का access है।

## Github Authentication

Github आपके account में authenticate करने और आपकी ओर से actions perform करने के विभिन्न तरीके ऑफर करता है।

### Web Access

**github.com** तक पहुँच कर आप अपने **username और password** (और संभावित रूप से **2FA**) का उपयोग करके login कर सकते हैं।

### **SSH Keys**

आप अपने account को एक या अधिक public keys के साथ configure कर सकते हैं जिससे संबंधित **private key आपकी ओर से actions perform कर सके।** [https://github.com/settings/keys](https://github.com/settings/keys)

#### **GPG Keys**

आप इन keys से user का impersonate नहीं कर सकते लेकिन अगर आप इसे उपयोग नहीं करते हैं तो ऐसा हो सकता है कि आप **commits बिना signature के भेजने पर पता चल जाएं**। इसके बारे में और जानने के लिए [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) देखें।

### **Personal Access Tokens**

आप personal access token generate कर सकते हैं ताकि कोई application **आपके account तक access पा सके**। Personal access token बनाते समय **user** को यह **निर्धारित** करना होता है कि token को कौन-कौन से **permissions** मिलेंगे। [https://github.com/settings/tokens](https://github.com/settings/tokens)

### Oauth Applications

Oauth applications आपसे permissions माँग सकते हैं **आपकी कुछ github जानकारी तक पहुँचने के लिए या आपकी नकल कर कुछ actions करने के लिए**। इसका एक सामान्य उदाहरण वह **login with github button** है जो आप कुछ platforms में देख सकते हैं।

- आप अपने खुद के **Oauth applications** यहाँ बना सकते हैं: [https://github.com/settings/developers](https://github.com/settings/developers)
- आप अपने account तक access रखने वाले सभी **Oauth applications** यहाँ देख सकते हैं: [https://github.com/settings/applications](https://github.com/settings/applications)
- आप देख सकते हैं कि **Oauth Apps किन scopes के लिए अनुरोध कर सकते हैं**: [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)
- आप किसी **organization** में third party applications का access _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ पर देख सकते हैं।

कुछ **security recommendations**:

- एक **OAuth App** को हमेशा **authenticated GitHub user के रूप में GitHub पर काम करना चाहिए** (उदा., user notifications प्रदान करते समय) और केवल निर्दिष्ट scopes तक ही access होना चाहिए।
- OAuth App को authenticated user के लिए "Login with GitHub" को सक्षम करके identity provider के रूप में उपयोग किया जा सकता है।
- **Don't** एक **OAuth App** बनाएं यदि आप चाहते हैं कि आपका application केवल **single repository** पर काम करे। `repo` OAuth scope के साथ, OAuth Apps authenticated user के सभी repositories पर काम कर सकते हैं।
- **Don't** OAuth App बनाएं जो आपकी **team या company** के लिए application के रूप में काम करे। OAuth Apps एक single user के रूप में authenticate करते हैं, इसलिए अगर किसी व्यक्ति ने company के लिए OAuth App बनाया और फिर वह व्यक्ति कंपनी छोड़ देता है, तो किसी और के पास उसका access नहीं रहेगा।
- **More** जानकारी के लिए [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps) देखें।

### Github Applications

Github applications permissions माँग सकते हैं ताकि वे **आपकी github जानकारी तक पहुँच सकें या आपकी नकल करके** specific resources पर कुछ actions कर सकें। Github Apps में आपको यह specify करना होता है कि app किन repositories तक access रखेगा।

- GitHub App install करने के लिए, आपको **organisation owner होना चाहिए या किसी repository में admin permissions** होने चाहिए।
- GitHub App को **एक personal account या एक organisation** से जोड़ना चाहिए।
- आप अपना Github application यहाँ बना सकते हैं: [https://github.com/settings/apps](https://github.com/settings/apps)
- आप अपने account तक access रखने वाले सभी **Github applications** यहाँ देख सकते हैं: [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
- ये हैं **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). App की permissions के आधार पर यह कुछ endpoints तक पहुँच सकता है।
- आप किसी **organization** में installed apps को _https://github.com/organizations/\<org_name>/settings/installations_ पर देख सकते हैं।

कुछ security recommendations:

- एक GitHub App को **user से स्वतंत्र रूप से actions लेना चाहिए** (जब तक कि app [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token का उपयोग न कर रहा हो)। user-to-server access tokens को और सुरक्षित रखने के लिए, आप ऐसे access tokens का उपयोग कर सकते हैं जो 8 घंटे के बाद expire हो जाएं, और एक refresh token जो नए access token के लिए exchange किया जा सके। अधिक जानकारी के लिए देखें "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
- सुनिश्चित करें कि GitHub App **विशिष्ट repositories** के साथ integrate हो।
- GitHub App को **एक personal account या एक organisation** से जोड़ना चाहिए।
- GitHub App से यह उम्मीद न रखें कि वह वह सब कुछ जान और कर ले जो एक user कर सकता है।
- **Don't use a GitHub App if you just need a "Login with GitHub" service**. लेकिन एक GitHub App [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) का उपयोग करके users को login करवा सकता है _और_ अन्य चीजें भी कर सकता है।
- यदि आप अपने app को GitHub Actions के साथ उपयोग कर रहे हैं और workflow files modify करना चाहते हैं, तो आपको user की ओर से authenticate करने के लिए OAuth token चाहिए जिसमें `workflow` scope शामिल हो। user को उस repository में admin या write permission होना चाहिए जिसमें workflow file है। अधिक जानकारी के लिए देखें "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
- **More** जानकारी के लिए [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps) देखें।

### Github Actions

यह **github में authenticate करने का तरीका नहीं है**, लेकिन एक **malicious** Github Action को github तक **unauthorised access** मिल सकता है और Action को दी गई **privileges** के आधार पर कई **different attacks** किए जा सकते हैं। नीचे अधिक जानकारी दी गई है।

## Git Actions

Git actions यह अनुमति देता है कि जब कोई event हो तो **कोड के execution को automate किया जाए**। आम तौर पर execute किया जाने वाला कोड **रिपॉजिटरी के कोड से संबंधित** होता है (जैसे docker container बनाना या यह जांचना कि PR में secrets तो नहीं हैं)।

### Configuration

_in_ https://github.com/organizations/\<org_name>/settings/actions_ में आप organization के लिए **github actions की configuration** देख सकते हैं।

आप github actions का उपयोग पूरी तरह से disallow कर सकते हैं, **सभी github actions की अनुमति दे सकते हैं**, या केवल कुछ select actions की अनुमति दे सकते हैं।

यहाँ यह भी configure करना संभव है कि **किसे Github Action चलाने के लिए approval चाहिए** और Github Action के run होने पर उस Action के **GITHUB_TOKEN की permissions** क्या होंगी।

### Git Secrets

Github Action अक्सर github या third party applications के साथ interact करने के लिए किसी प्रकार के secrets की आवश्यकता होती है। इन्हें repo में clear-text में रखने से बचाने के लिए, github इन्हें **Secrets** के रूप में रखने की अनुमति देता है।

ये secrets **repo के लिए या पूरी organization के लिए** configure किए जा सकते हैं। फिर, ताकि **Action secret तक access कर सके**, आपको इसे इस प्रकार declare करना होगा:
```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 }}
```
#### 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]
> Secrets **केवल उन Github Actions से ही एक्सेस किए जा सकते हैं** जिनमें वे declare किए गए हों।

> एक बार repo या organizations में configure होने के बाद **users of github फिर उन्हें access नहीं कर पाएँगे**, वे केवल उन्हें **change** कर सकेंगे।

इसलिए, **github secrets चोरी करने का एकमात्र तरीका यह है कि आप उस मशीन तक पहुँच सकें जो Github Action चला रही है** (ऐसी स्थिति में आप केवल उन secrets तक ही पहुँच पाएँगे जो उस Action के लिए declare किए गए हैं)।

### Git Environments

Github आपको ऐसे **environments** बनाने की अनुमति देता है जहाँ आप **secrets** सेव कर सकते हैं। फिर, आप github action को उस environment के अंदर के secrets तक access देने के लिए कुछ ऐसा दे सकते हैं:
```yaml
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.\
Additionally, environment protections include:
- **Required reviewers**: gate jobs targeting the environment until approved. Enable **Prevent self-review** to enforce a proper four‑eyes principle on the approval itself.
- **Deployment branches and tags**: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the "Protected branches only" option applies to classic branch protections and may not behave as expected if using rulesets.
- **Wait timer**: delay deployments for a configurable period.

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

Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.

You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_

The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml.

It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs.

If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with.

### Git Action Compromise

If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed.

> [!CAUTION]
> 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)
> - **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

Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.

The **branch protections of a repository** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_

> [!NOTE]
> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.

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 approval of the most recent reviewable push**. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
- **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 need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., "@bot-name skip").
- **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.
- **Require linear history.** Prevent merge commits from being pushed to matching branches.
- **Include administrators**. If this isn't set, admins can bypass the restrictions.
- **Restrict who can push to matching branches**. Restrict who can send a PR.

> [!NOTE]
> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.

## Tag Protections

Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow on tag updates, protect tags and chain protections through environments and branches:

1) On the tag protection rule, enable **Require deployments to succeed** and require a successful deployment to a protected environment (e.g., prod).
2) In the target environment, restrict **Deployment branches and tags** to the release branch (e.g., main) and optionally configure **Required reviewers** with **Prevent self-review**.
3) On the release branch, configure branch protections to **Require a pull request**, set approvals ≥ 1, and enable both **Dismiss approvals when new commits are pushed** and **Require approval of the most recent reviewable push**.

This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.

## References

- [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)
- [https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
- [https://securitylab.github.com/resources/github-actions-untrusted-input/](https://securitylab.github.com/resources/github-actions-untrusted-input/)
- [https://docs.github.com/en/rest/checks/runs](https://docs.github.com/en/rest/checks/runs)
- [https://docs.github.com/en/apps](https://docs.github.com/en/apps)
- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)

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