With the new Gateway resource is IAP still configured the same way using BackendConfig or has this changed?
I'm using the new Kubernetes Gateway Resource to create an external loadbalancer to expose services.
https://cloud.google.com/kubernetes-engine/docs/how-to/gatewayclass-capabilities#gateway
I use a GKE Backend config to enable IAP. This doesn't appear to properly enable IAP on the backend service that gets created.
The gateway resource shows the error
Warning SYNC 28s sc-gateway-controller error ensuring load balancer: generic::invalid_argument: Update: Invalid value for field 'resource.iap.oauth2ClientId': ''. IAP OAuth2 client ID must be set if IAP is enabled.
However my BackendConfig resource correctly sets the oauth2credentials secret (see below)
When I go to the IAP UI, I see an error that the oauth client id is not set and telling me to reenable IAP. When I reenable IAP on the backend service via the UI; it is turned on and everything works correctly. The only place I specified the OAuth2 config is in the BackendConfig so it does appear to be getting the OAuth2 credentials from there.
The documentation is unclear about whether this is supported or not. I'm not sure if the "-" for IAP on the capabilities page means IAP doesn't work with the gateway resource or it means its not configured by the gateway resource but via the BackendConfig. I'm assuming the latter.
I'm using the gateway class: gke-l7-global-external-managed
Here's the YAML for my GKEBackendConfig
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: mesh
spec:
healthCheck:
type: HTTP
requestPath: /healthz/ready
port: 15021
iap:
enabled: true
oauthclientCredentials:
secretName: iap-oauth
Hello jlewi,
Welcome to Google Cloud Community!
You may use these documents for Enabling IAP in GKE and Configuring BackendConfig.
I'm following those docs. I'm setting my BackendConfig as provided in my original post but the gateway controller is giving me an error and not turning on IAP unless I toggle it on and off.
IAP is not currently supported by Gateway, but we will be releasing support soon!
Couldn't find any issue around this, but I created https://issuetracker.google.com/issues/286372106 sadly after I saw garisingh comment about it's coming.
Ohh well, hopefully people be able to find this post trough there if nothing else.
IAP is now available for the GKE Gateway:
https://cloud.google.com/kubernetes-engine/docs/how-to/configure-gateway-resources#configure_iap
Thanks @rueth - is there a way to apply IAP to only a path?
I have two paths that go to the same backend service - /api, and /console - I want to only put /console behind IAP.
Thanks
What I have done for now is to define two services and apply IAP to one service. The services target the same pods, but are matched to all the paths that need IAP.
Is this expected to work in clusters where an Ingress has never been configured (only Gateways)?
Reason being is that the documentation linked says: "If you don't see a resource, ensure that the resource is created and that the BackendConfig Compute Engine ingress controller is synced." But [this](https://cloud.google.com/kubernetes-engine/docs/how-to/configure-gateway-resources#configure_iap) says not to configure the BackendConfig...kind of contradictory...what should I do? What resource should I create? I already see a healthy 'gke-l7-rilb' class loadbalancer corresponding to the existing Gateway in my cluster, but no resources show up on the Identity Aware Proxy page for which to create credentials...what next?
For Gateway you should be using the GCPBackendPolicy resource.
For Ingress you use the BackendConfig resource.
When they say Ingress, they are referring to the GKE Ingress controller which is enabled via the HttpLoadBalancing add-on(https://cloud.google.com/kubernetes-engine/docs/how-to/load-balance-ingress). Not ingress traffic in general.
The GKE Gateway controller is Google's implementation of the Gateway API for Cloud Load Balancing. Similar to the GKE Ingress controller, the Gateway controller watches a Kubernetes API for Gateway API resources and reconciles Cloud Load Balancing resources to implement the networking behavior specified by the Gateway resources.
Unlike the GKE Ingress controller, the Gateway controllers are not hosted on GKE control planes or in the user project, enabling them to be more scalable and robust. Both Gateway controllers are Generally Available.
There is more information available here:
https://cloud.google.com/kubernetes-engine/docs/concepts/gateway-api#ingress_and_gateway
Yes, thanks for the general info on the k8s resource types; I think I'm clear enough on the differences, but maybe unclear on whether my overall goal is achievable--basically, I'm trying to expose an API which runs in GKE and is exposed via a Gateway resource through an IAP tunnel.
For context, I have IAP roles assigned, and firewall rules allowing access to a vpc where a bastion host is running which has no external IP; I can successfully ssh to that instance in the console, and via gcloud cli (start-iap-tunnel or the ssh variety).
I have a Gateway showing as healthy in the gke Gateways view (and via kubctl commands), but which has only an internal IP; I want to open an IAP tunnel to that gateway's lb on a specific port to test my API....is this a thing that's possible? Or do I just need to tunnel through a bastion host?
I see that the subnet to which this lb is attached has the appropriate iap-allowing ingress firewall rules, and my bastion host on that same subnet can be connected via IAP as mentioned previously....so where do I go from here? Maybe I'm missing some understanding here of what IAP can/can't connect to...
Thanks in advance!
Enabling IAP for a GKE Gateway backend service via a GCPBackendPolicy only enables authentication and authorization to that backend via IAP. It does not enable IAP tunneling like
gcloud compute ssh VM-NAME --tunnel-through-iap
You would need to setup the network connectivity to be able to get to the IAP enabled GKE Gateway from where ever the request is originating. Since you are using IAP for the gateway, you could expose it via an external gateway instead of internal depending on your use case.