Table of Contents
Enable member access to your GitHub Organization
Prerequisites
-
You are the owner of the respective GitHub Enterprise organization.
-
You manage at least one grouping with the GitHub Team sync destination enabled and the person you are inviting is a member of that grouping.
Steps
-
Obtain the member’s GitHub account name and UH Username.
-
Add the member to your UH grouping for managing memberships.
-
Invite the member to your org using the member’s GitHub account name.
Troubleshooting
-
If a member is invited, but cannot access our GitHub Enterprise, check to ensure that:
-
you have a grouping to which this person has membership,
-
the grouping has the GitHub Team sync destination enabled. (1)
-
If a member reports that when they attempt to login their password is rejected, it is possible that they need to perform a password reset first. (2)
-
You are an owner of the grouping and cannot access our GitHub Enterprise, ensure that owners are also added to the grouping Include list.
Footnotes
(1) The GitHub Team sync destination is required for enabling a member’s access to the UH GitHub Enterprise via our Microsoft Entra ID tenant. UH Login now also incorporates Entra ID.
(2) Existing UH Login password hashes are not accepted by our Entra tenant. It must create its own hashes, which happens during account creation and during password resets. We do not retain a copy of passwords in cleartext for security reasons.
Enable collaborate access to your GitHub Organization
You can allow people who aren't members of your organization to access repositories that your organization owns.
GitHub provides more information in
this article.
Security Recommendations
Securing GitHub Actions
SHA Pinning
Previously, developers use tags (e.g., uses: actions/checkout@v4). Since tags are mutable they are subject to supply-chain attacks. If a maintainer's account is compromised, an attacker can move the v4 tag to point to a malicious commit, instantly injecting code into your organization's internal build pipelines. Requiring SHA pinning (using the 40-character commit hash) at the organization level enforces immutability.
-
Immutable Security: A commit SHA is a unique cryptographic fingerprint. Unlike tags, it cannot be changed or moved to point to different code.
-
Prevent Supply Chain Attacks: It eliminates "tag-flipping" attacks, ensuring that the code you audited yesterday is the exact code that runs today.
-
Enforced Governance: Setting this at the organization level prevents "shadow IT" and ensures all teams adhere to the highest security standards without exception.
Instructions: require SHA pinning for all applications in your organization.
Setting Permissions
By default, the GITHUB_TOKEN provided to a workflow can sometimes have broad "Read/Write" access. If a malicious action (or a bug in a legitimate one) is executed, it could use those permissions to delete packages, overwrite code, or exfiltrate secrets.
Your organization is, by default, set to read-only, which is good. When a workflow actually needs to do work (like publishing a package or commenting on a PR), explicitly grant only those specific permissions in the YAML file. For example:
permissions:
contents: read
security-events: write
GitHub Documentation