Allow Kubernetes Runtime

[lnrdll]

The current application is limited to running on AppEngine or Cloud Run due to runtime constraints. This feature request seeks to expand the deployment options to include Kubernetes as well.

[jpassing]

Technically, that wouldn't be very difficult -- it might even work already.

But I'm not sure if it's a good idea to deploy JIT Access to Kubernetes: JIT Access (or more precisely, its service account) has privileged (Security Admin) access to the projects it manages. It's therefore important to lock down access to that service account. When you deploy JIT Access in its own project (as the documentation recommends), you have pretty good control over who can access the project and the service account.

When you deploy JIT Access into a shared Kubernets cluster, controlling access gets more complex -- now you not only have to worry about IAM access to the project, but also about RBAC within the shared cluster, and there's an increased risk that somebody might inadvertently end up having access to the JIT Access service account, which they could then use to "privilege escalate" their way into other projects. From a security perspective, I think Cloud Run or AppEngine is simply less risky.

[lnrdll]

Ok.

The intention was simply to provide assistance to those who are already familiar with Kubernetes due to their preference for it as their underlying infrastructure. Implementing, overseeing, and ensuring the security of Just-in-Time (JIT) deployment wouldn't pose significant challenges for individuals who are already accustomed to managing Kubernetes for other purposes.

I've made an attempt at deploying JIT within a Kubernetes cluster, but unfortunately, the process was unsuccessful. The application includes a condition to verify the runtime environment, and I am hesitant to fork the codebase solely to address this condition.

[lauraseidler]

@jpassing I know this was closed, but if possible, I'd like to re-open the issue. I understand the concerns you outlined, but our use case is a little different:

We're a platform team running and managing Kubernetes clusters, and we'd like to deploy JIT access mostly for developers - who don't have access to the cluster or service account we'd use to deploy JIT access, and the permissions we'd like to make JIT accessible are not related to it either, so this is a non-issue. We're not currently running anything on App Engine or Cloud Run, and we'd like to avoid making things more complicated for our team and stick with K8s.

I'll see if we can get this running as-is by pretending to be Cloud Run - as you said, it might work already. Otherwise, would a PR for this be acceptable, as long as it comes with an explicit warning about the security concerns?

[jpassing]

would a PR for this be acceptable, as long as it comes with an explicit warning about the security concerns?

Yes, absolutelty.

If you set up workload identity and set the environment variable K_SERVICE, then it might just work. But modifying the RuntimeEnvironment class to explicitly allow GKE deployments might still be useful.

[userbradley]

I was able to get this to run in to GKE

Somethings to note:

Use Workload Identity

Using workload Identity allows you to grant a specific service account to the deployment. Doing it using service account keys is something you should not think about.

I have some documentation I wrote if you get stuck

Tricking the application in to thinking it's on clourdrun

In the code, it checks where the deployment is running, I was able to get to to think it's on cloudrun by setting the below environment variable

   K_SERVICE: "yes"

IAP backend service

Because IAP is deployed at the same time as the application, getting the IAP backend service was a pain, and until I find a solution meant deploying the app twice

Below assumes your service/ load balancer is called just-in-time

gcloud compute backend-services list | grep just-in-time

This will give you the Load balancer UUID

gcloud compute backend-services describe <uuid of lb> --global --format 'value(id)')

You then need to set the environment variable IAP_BACKEND_SERVICE_ID for the deployment

---

Closing notes

This was very hacky, but worked well provided you have an abundance of GKE clusters knocking about, or have a service GKE cluster for internal tools etc.

You will also need to then lock down the cluster significantly (think RBAC, VPC native cluster etc) and ensure that very few people have access to the cluster, as if they have access to the namespace JIT runs in, they can deploy a pod using the JIT ksa and make API calls to get higher permissions as them selves