How do I give read-only access to some users in another department?

[Rod-at-DOH]

🏷️ Discussion Type

Question

Body

I work in one of my state's largest state government departments. I'm on a team of GitHub Administrators for the state department I'm in. Our access to GitHub is through another state department, which is the IT department. This IT department is what grants us access to GitHub. Everything we do has to go through a portal they have in place. It works fine.

The IT department wants to perform scans of some of our repos for vulnerabilities. One way this could happen, they tell me, is if the GitHub Admin team I'm on were to give them read-only access to the GitHub repos we grant them access to. As they put it, we could grant them access "via a deploy key, read-only token, or read-only collaborator".

I've not done this before, and I don't believe my co-admins have either. The read-only collaborator is something I've read about, but we've never done. Currently, all users in our GitHub Enterprise and Organizations, MUST have a GitHub account using their email address associated with our domain. So, what they're proposing doesn't fit into the scheme we currently use. So, I'm asking for guidance as to how we should proceed, please.

[meruw]

I’d recommend using a GitHub App with read-only access to only the repositories that need to be scanned.

That keeps the scanner separate from normal user accounts, avoids creating an external collaborator, and gives you better control over permissions and auditing.

If a GitHub App isn’t supported, a read-only deploy key would be my next choice for simple repository access.

[Rod-at-DOH]

What is a read-only deploy key? How do I create one?

[meruw]

A read-only deploy key is an SSH key attached directly to a single repository, rather than to a GitHub user. Whoever has the private key can clone/fetch that repository, but cannot push changes when the key is read-only.

For your vulnerability-scanner example, IT would normally generate the SSH key pair on the scanner/server. You would then add only the public key in GitHub:

Open the repository → Settings
Go to Security → Deploy keys
Click Add deploy key
Give it a descriptive name, such as IT Vulnerability Scanner
Paste the public SSH key
Do not enable write access as deploy keys are read-only by default.

Then the scanner keeps the private key and can clone with SSH, for example:

git clone git@github.com:organization/repository.git

Also, you need to know that a deploy key only grants access to one repository. So if IT needs access to many repos, you'd need separate deploy keys for each, which is one reason a GitHub App can be easier at scale. Deploy keys also don't expire automatically, so they should be reviewed and rotated/revoked when no longer needed.

Also, since you're using GitHub Enterprise, the enterprise owner can disable deploy keys entirely through enterprise policy.

[tanishworks]

You can invite them as a collaborator, for which they would need a github account.
The other way is a read-only deploy key, however it is limited to one repository.
The best recommended way is using GitHub apps. You can have fine control over what they can do and access with the repo.
I don't know much about working with orgs but here is an ai overview

There are two possibilities.

1. The IT department already has a vulnerability-scanning product with a GitHub App

This is the easiest case.

They give you their GitHub App installation URL. You, as an organization owner/admin, install it into your organization.

During installation, GitHub lets you choose:

All repositories
or
Only select repositories

You'd choose Only select repositories and select the repos they're supposed to scan. GitHub explicitly supports restricting an app installation to selected repositories.

You then review the permissions the app requests. For a scanner that merely needs to clone/read source code, you'd expect something along the lines of:

Repository permissions

Contents: Read-only
Metadata: Read-only

The exact permissions depend on what their scanner needs. GitHub recommends giving an app only the minimum permissions it requires.

2. They want you to create a GitHub App specifically for the scanner

That's also possible, but there's an important distinction.

You could create an app owned by your organization, configure its permissions, and give the IT department the credentials needed to authenticate as that app.

For Git-over-HTTPS, GitHub Apps can use an installation access token as the authentication credential. With the Contents repository permission, that token can be used for HTTP-based Git access.

So conceptually:

GitHub App
│
│ installation
▼
Your organization
│
├── repo1 ✓
├── repo2 ✓
├── repo3 ✓
└── secret-repo ✗

IT scanner
│
└── authenticates as the App

No collaborator account. No personal account. No domain-email exception.

There's another nice property here

You can change what the app can access later.

Organization owners can review installed apps, see their permissions, change repository access, or suspend/delete the app.

So if IT says:

"We need to scan these 14 repositories."

you can give the app those 14 repositories rather than giving some IT account access to the entire organization.

And when the scanning project ends, you remove/suspend the installation.

I all depends whether the IT dept has a github app or you are supposed to make one

[Rod-at-DOH]

You are correct, we will have to give the IT department access to several repos. At this point I don't know how many, but I do know that one isn't enough. The odd thing to me is since we have to use the IT department's portal and they grant us access to GitHub, wouldn't that mean they already have access to our GitHub Enterprise and all Organizations?

[kittimzhe]

Your domain-email rule applies to human accounts, not machine identities — so this is easier than it looks: use a GitHub App, not a collaborator or a key. An app has no user account, so it never touches your "must use a department-domain email" policy.

Two routes, pick one:

A. Their scanner probably already ships as a GitHub App (most SAST / secret-scanning vendors do). Ask them for the installation URL; as an org owner you install it and select "Only select repositories", then grant nothing beyond Contents: Read + Metadata: Read. Done — no human account, no external collaborator, no email exception.

B. If they have no app, create an org-owned GitHub App (Settings → Developer settings → GitHub Apps), give it Contents: Read-only + Metadata: Read-only, install it on only the repos to scan, and hand their scanner an installation token. Same result — an identity that isn't a person.

Why not the alternatives they proposed:

• Read-only deploy key: grants access to one repo per key (tedious across many repos), and on GitHub Enterprise org admins can restrict deploy-key usage org-wide. Fine for 1–2 repos, but the App scales and audited better.
• "Read-only collaborator": there's no role that dodges the account requirement — GitHub's lowest role (Read, formerly triager) still demands a real GitHub user, which breaks your domain-email rule. Skip it.

So: GitHub App, scoped to selected repos, Contents + Metadata read-only — that's the option that fits your constraints exactly.

[Rod-at-DOH]

Thank you for this additional information! I'll check with them to see if they have a GitHub App and can provide me with the installation URL.

[kittimzhe]

Good — the App route it is. On your follow-up (“don't they already have access through the portal?”): usually no, not in the way that matters here — because granting access ≠ reading repository contents.

Your IT department runs the portal that provisions your identities — SSO, which accounts may sign in, group entitlements. That's the identity & access-management layer: it lets them decide who may log in, but it does not automatically give any of their accounts (or their scanner) read access to the files in your repos. Reading repository contents is a separate grant — org membership/role, an outside collaborator, a deploy key, or a GitHub App installation.

The GitHub App you're about to install is exactly that second, scoped grant: it lets their scanner read only the selected repos' contents — and nothing else — while the portal still controls the human logins. It also gives you an audit trail of everything the app touched, which an umbrella "they probably already have access" wouldn't give you.

So no conflict. If anything, you can tell them the App scoped to selected repos (Contents + Metadata read-only) is the least-privilege way to do it — that phrasing generally lands well with an IT/security team. 👍