GitHub access in Studios
A Studio uses your GitHub connection to clone, push and run gh as you. This page explains how that access reaches the Studio and why it's limited the way it is. To set it up, see Connect GitHub to your Studios.
Why GitHub access works this way
A Studio runs code: yours, your collaborators', and code you download. Anything a Studio holds, that code can read. A GitHub credential stored in a Studio is only as safe as everything that ever runs there, for as long as the credential lasts.
So a Studio holds as little GitHub access as it can, for as short a time as it can:
- Limited permissions. The Lightning AI GitHub App asks only for what everyday development needs. It can't change workflow files, repository secrets or deployments.
- Limited repositories. The app can access only the repositories you or your GitHub organization's admins choose.
- Short-lived. Each token a Studio gets stops working within eight hours.
- Nothing stored in the Studio. No GitHub credential is written to the Studio's disk or put in its environment variables.
How GitHub access works
When you connect GitHub, Lightning AI stores your connection's long-lived credential encrypted on its own servers, and uses it there to get short-lived tokens. The long-lived credential is never sent to a Studio.
When git or gh in a Studio needs GitHub, it asks the Studio for a token. The Studio fetches a short-lived one from Lightning AI, keeps it in memory for up to ten minutes, and hands it to the command. That's why disconnecting GitHub on Integrations takes up to ten minutes to reach a running Studio.
GitHub decides what that token can do. It allows an action only when all three of these do:
- The app's permissions.
- The repositories the app is installed on.
- Your own access on GitHub.
A repository you can read on GitHub but haven't chosen for the app is out of reach from a Studio, and so is anything the app has no permission for.
Your own login
gh auth login in a Studio replaces the app's limited permissions with your full user permissions, so it has tighter limits:
- It lasts for the time you choose, eight hours at most.
- It's kept in the Studio's memory and never written to its disk, so it ends when the Studio stops.
- When it ends, Lightning AI revokes it on GitHub. When the Studio stops, Lightning AI tries to. If the Studio stops without warning, the login still stops working on GitHub within eight hours.
Who can use your access in a Studio
Any code running in the Studio can ask for a token the same way git does. That includes everyone working in the Studio: collaborators on a shared Studio act on GitHub as you, with your connection, and with your own login while one is active. It works both ways: if a collaborator runs gh auth login in your Studio, everyone in it, you included, acts on GitHub as them until that login ends.
The limits above are what keep this contained. Before you share a Studio or run code you don't trust, check which repositories the app can access, and end your own login with gh auth logout.
Personal access tokens
A personal access token you set in GH_TOKEN, or in one of the other variables gh reads, always wins over your GitHub connection. It has none of the limits above: it sits in the Studio's environment for as long as it's set, and it lasts as long as you made it last on GitHub. If you use one, make it a fine-grained token for only the repositories and permissions you need.
When a Studio doesn't use your connection
A Studio doesn't get access from your GitHub connection in these cases:
- It was created without secrets, an option when you create a Studio through the API.
- It was transferred to a new owner while running. Restart it to use the new owner's connection.
- Its owner no longer has access to the teamspace.
gh auth login still works in a Studio like this.
See also
Was this page helpful?
Thanks for the feedback.