Identity Federation

[numbsafari]

Hi,

This is probably a super big ask, but I think it is potentially huge.

Right now, when I am using a Code Space, it appears as though it is private to me as a user. Is that correct? That is, within a repository, the code space instances can't be shared by separate users. Yes, each user can have separate instances using the same images, &c, but the actual disk and contents are running for the individual user. I'm assuming that, given how the dotfiles and other things are mapped in.

Anyhow, what would be awesome, is if there was a workload identity available for that instance that identified my GitHub user account, within the context of the organization and repo that I am working in. With this, if it is exposed somehow as a JWT with a public GitHub OIDC provider, I can then integrate my identity with Google Cloud, AWS, etc.

Reference topics:

• SPIFFE
• GCP Workload Identity Federation
• AWS OIDC Providers

My understanding is that some form of workload identity is coming to GitHub Actions. Pairing that same approach with Code Spaces would create a tremendous foundation for security.

[numbsafari]

Just stopping by to add a link to the GitHub Actions OIDC support:

https://github.blog/changelog/2021-10-27-github-actions-secure-cloud-deployments-with-openid-connect/

[asciimike]

We've definitely considered the actions type approach to allow easier auth to cloud platform providers. It is worth noting that some amount of the existing cloud provider infra e.g. gcloud auth login will work (and will do the right auth bump), but it's not as seamless as it could be.

[numbsafari]

Thanks for responding. I also found this write-up from the docs very helpful: https://docs.github.com/en/codespaces/codespaces-reference/security-in-codespaces

For my current arrangement, I'm setting up restricted service accounts associated with each user. The user can then generate a key and save it as a GH secret with a well-known name. Our devcontainer has bootstrap scripts to take that secret and put it where gcloud tooling expects it to be.

This makes it a bit more seamless (no need to re-auth on restarts, etc.), and also follows Google's recommended best practices around exposing User auth tokens in "shared" environments. If something happens to expose the contents of the codespace, the user's account itself isn't compromised. It also helps bifurcate access from the codespace to our production assets for those users who can access both. The codespace SA can only see dev resources, or the user open a PR via GH and make changes through CI. For prod access the user can log into Cloud Console and work from there either via CloudShell, or ClickOps-style.

I believe through GCP's identity federation we would have a similar experience where the federated identity mapped to the GH identity could be setup with limited dev access. Federated identity would avoid the overhead and bad UX of provisioning the service accounts and secrets directly for each user, have better rotation, prevent impersonation, and avoids the risks of secret env var disclosure. We might also be able to work with outside contributors who need limited GCP dev access, but for whom we don't necessarily want to create a full Workspace identity. I don't think I'd personally do that, but I could see others wanting it.

Posting this here mostly for anybody who might have similar concerns and need an approach. Also open to feedback on improvements to the above.

Really loving codespaces!

[jcity]

I'm getting started with codespaces so forgive me if this already exists. I haven't seen it in the docs yet.

I want to start a codespace from a custom docker image from a private ECR repo. Right now, I think the only way is to create an IAM user/keypair and then set the AWS_CONTAINER_REGISTRY_SERVER, AWS_CONTAINER_REGISTRY_USER, AWS_CONTAINER_REGISTRY_PASSWORD variables.

With actions I can use the OIDC provider to authenticate. It would be great to use the same auth mechanism in codespaces too.