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

Reading time: 19 minutes

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

एक बड़े 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

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

आप अपने खुद के 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

GPG Keys

आप इन keys से user का impersonate नहीं कर सकते लेकिन अगर आप इसे उपयोग नहीं करते हैं तो ऐसा हो सकता है कि आप commits बिना signature के भेजने पर पता चल जाएं। इसके बारे में और जानने के लिए vigilant mode here देखें।

Personal Access Tokens

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

Oauth Applications

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

• आप अपने खुद के Oauth applications यहाँ बना सकते हैं: https://github.com/settings/developers
• आप अपने account तक access रखने वाले सभी Oauth applications यहाँ देख सकते हैं: https://github.com/settings/applications
• आप देख सकते हैं कि Oauth Apps किन scopes के लिए अनुरोध कर सकते हैं: 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 देखें।

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
• आप अपने account तक access रखने वाले सभी Github applications यहाँ देख सकते हैं: https://github.com/settings/apps/authorizations
• ये हैं API Endpoints for Github Applications: https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. App की permissions के आधार पर यह कुछ endpoints तक पहुँच सकता है।
• आप किसी organization में installed apps को https://github.com/organizations/<org_name>/settings/installations पर देख सकते हैं।

कुछ security recommendations:

• एक GitHub App को user से स्वतंत्र रूप से actions लेना चाहिए (जब तक कि app user-to-server token का उपयोग न कर रहा हो)। user-to-server access tokens को और सुरक्षित रखने के लिए, आप ऐसे access tokens का उपयोग कर सकते हैं जो 8 घंटे के बाद expire हो जाएं, और एक refresh token जो नए access token के लिए exchange किया जा सके। अधिक जानकारी के लिए देखें "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 का उपयोग करके 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."
• More जानकारी के लिए here देखें।

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 करना होगा:

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 का उपयोग करते हुए उदाहरण

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

एक बार 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 देने के लिए कुछ ऐसा दे सकते हैं:

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.

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

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.

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/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprisehttps://docs.github.com/en/enterprise-server
• 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/actions/security-guides/encrypted-secrets
• https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions
• https://securitylab.github.com/resources/github-actions-untrusted-input/
• https://docs.github.com/en/rest/checks/runs
• https://docs.github.com/en/apps
• GitHub Actions: A Cloudy Day for Security - Part 1