Open aebrahim opened 3 months ago
JIT Access completely relies on IAP for authentication and authorization. To verify that (a) IAP is enabled at all and (b) that a request has indeed being vetted by IAP, JIT Access verifies the x-goog-iap-jwt-assertion
header. For that, it needs to know what audience to expect in the header.
On AppEngine, the expected audience can be derived from the project ID. On Cloud Run, there's no way for the application to determine the audience automatically, hence the need for the IAP_BACKEND_SERVICE_ID
variable.
To break the cyclic dependency between the load balancer and Cloud Run, you can deploy things in the following order:
That's the sequence followed by the manual setup instructions. Maybe you can get Terraform to follow this sequence by using depends_on
?
Thanks @jpassing for the response!
Unfortunately, to the best of my knowledge, depends_on
doesn't resolve circular dependencies, it only pulls an unconnected dependency into the dependency graph for the current node.
Is there a way we can rely on the terraform configuration to ensure that all traffic flowing in to the jit-access service has already been authenticated and authorized by IAP, and use a new flag to skip re-validation in jit-access? If this is possible, IMHO, the requirement to break infrastructure as code and require a superuser to perform manual steps negates any security improvement from a re-validation of an already validated token.
What should work is to...
gcloud compute backend-services create jitaccess-backend \
--load-balancing-scheme=EXTERNAL \
--global
I know it's not great, but (1) is a one-time thing, so any subsequent deployments could be fully automatic.
I do not see a good way to create the cloud run job using an infrastructure as code solution like terraform due to the circular nature of the requirement to specify the
IAP_BACKEND_SERVICE_ID
in the cloud run service itself, which needs to be created before the backend service can be created.This is sample failing terraform configuration:
Can the required environmental variable
IAP_BACKEND_SERVICE_ID
be removed from the cloud run job? From the docs, I am not clear on why the cloud run job needs to be aware of the IAP environment feeding traffic to it.