Contractor repository access: public entry or VPN path?

A contractor needs one private repository for a limited project, and the request arrives as either "make the repo public" or "give them VPN access." Both answers skip the real question. Repository authorization and network entry are separate layers, and the permission that matters is the one that lets that person read or push to that one repository. Everything else in either bundle is extra risk. Design the authorization layer first, then decide how little network path it needs.

An illustrative engagement makes this concrete: one external developer, one repository, no production hosts, no administration interface. Keep that scope fixed while you compare the entries.

Two entries, two different boundaries

A publicly reachable repository service still enforces HTTPS or SSH authentication and application authorization. Public reachability does not mean anonymous readability. The cost is a listener you have to maintain, monitor and patch.

A VPN entry can keep that listener off the public path, but a broad VPN account may expose unrelated services. A leftover public hostname, an SSH listener, or an address family you forgot can defeat the VPN-only boundary you thought you had. That is why a VPN-only design needs an inventory of listeners, not just a firewall rule.

Compare permitted paths, not labels. Either way, keep application authentication and normal server-identity validation in place.

Repository roles are the unit of permission

Give the contractor an individual identity with the smallest role that completes the task. Viewing, pushing, maintaining and administering are different roles, and a group that grants every internal project is not the same as access to one repository. Check the actual role names in your platform instead of assuming a group name maps to one role.

List every operation the engagement actually needs. Browser access and Git transport may use different credentials or listeners. Automated builds, package downloads and webhooks can run as separate identities with their own delivery paths, and a VPN on the laptop does not connect those.

Protecting the repository's contents is a separate job. Changing the entry path does not remove a secret already in history, restrict an authorized clone, or secure a contributor's workstation.

Credentials that outlive the person

Offboarding is where repository access and network access diverge again. Remove the repository authorization and the VPN entitlement through their respective owners, then check personal tokens, SSH keys, automation credentials and active sessions. A deploy key is the classic survivor: it can keep its configured read or write access after the person leaves the organization. Removal from a membership list is not complete offboarding.

Inventory machine credentials by owner and purpose before the engagement ends, not after. A token created for a one-week build can outlive the project by a year if nobody wrote down why it exists.

Verify the operation, the denial and the offboarding

Before handover, test three things: the permitted repository operation succeeds, an unrelated repository is denied, and the retired identity fails. If the design is VPN-only, confirm the old direct public route can no longer perform the operation.

Keep the code and the review records, but do not let forgotten access become the recovery plan. A written list of identities, roles and expiry dates is what makes the next contractor request a repeatable process.