How do Secure Web Proxy rules filter requests sent by containers ?

[gberche-orange]

Hello,

Hello, Secure Web Proxy (SWP) documentation at https://cloud.google.com/secure-web-proxy/docs/overview mentions :

> The web requests can originate from the following sources: [...] Containers [...]
> Secure Web Proxy enables flexible and granular policies based on cloud first identities and web applications.

In particular, I need rules to identify a particular container (say a pod in a GKE cluster, or a pod in an openshift cluster provisionned through GCE vms), in order to grant access to some destinations conditionally based on the container originating the traffic to the secure web proxy.

Reading the CEL reference at https://cloud.google.com/secure-web-proxy/docs/cel-matcher-language-reference#available-attributes-i..., I can not yet see container related identity that would enable granular policies based on containers.

As I understand the GKE Tags from https://cloud.google.com/kubernetes-engine/docs/how-to/tags, GKE tags are assigned to the whole GKE cluster and can not be assigned on a per pod basis. Therefore the source.matchTag(SECURE_TAG) CEL expression can not be used to distinguish source containers.

Does SWP plan to support clients authentication to proxy as specified in https://datatracker.ietf.org/doc/html/rfc9110#section-11.7 ?

The only workaround I could imagine so far to apply distinct SWP rule for distinct containers is a combination of

- dedicate a SWP instance per container

- restrict container egress traffic and only grant each container access to its own SWP proxy IP address.

Is there another approach available in SWP to filter requests differently for each container ?

Thanks in advance,

Guillaume Berche.

ps: Sorry if this message has not the appropriate labels attached, I could not see yet a Network Security category available to choose from.

[Polinsky · Accepted solution]

Hi Guillaume,

You are correct that secure tags cannot be assigned on a per-pod basis, so they won't give you the granularity that you need, and SWP does not support Client Authentication.

The workaround you propose could work, although I realize it's not ideal for you. The team is investigating other potential workarounds that may be cleaner and we hope to get back to you soon.

Thanks!

Edit: I noticed this was automatically marked as a solution and resolved, but we're still working on it!

[ngprabhu-google · Accepted solution]

Hi Guillaume -

1. Regarding Openshift, the workaround you described should work in theory. You would probably need to have a namespace reference a single pod if you want to segment the source per pod, but should then be able to use the "egress IP" in a SWP policy to match the source.
2. Regarding supporting this natively in GKE, we have started discussing this internally, but we don't have a committed timeline yet. 

Thanks,
Naveen

[Gokhan · Accepted solution]

Hello,
we are working on exact same scenario, the difference is, we are considering workload identities. 
If we enable Workload Identity federation, then match GKE Service Accounts, with IAM service accounts, can we make filters for those service accounts?  

[kevinam · Accepted solution]

For GKE service account are managed slightly different.  For VMs service-account information is derided from the Andromeda unique identifier (AEID), for GKE the container/app needs to query the metadata service to receive a token (JWT) which is provided in the HTTP header.

JWT support is on the roadmap.  Please reach out to the SWP PM ngprabhu@ to provide more customer context for prioritization.

[Gokhan · Accepted solution]

@ngprabhu-google 
how can I reach to you? 

[ngprabhu-google · Accepted solution]

Hi - Unfortunately we do not have a public roadmap that we publish. You can reach out to me directly at ngprabhu@google.com.

[ngprabhu-google · Accepted solution]

You can reach out to me at ngprabhu@google.com

[Polinsky · Accepted solution]

Hi Guillaume,

You are correct that secure tags cannot be assigned on a per-pod basis, so they won't give you the granularity that you need, and SWP does not support Client Authentication.

The workaround you propose could work, although I realize it's not ideal for you. The team is investigating other potential workarounds that may be cleaner and we hope to get back to you soon.

Thanks!

Edit: I noticed this was automatically marked as a solution and resolved, but we're still working on it!

[gberche-orange]

Thanks Polinsky for your response.

We are considering another workaround of assigning static dedicated egress ip addresses per namespace using an openshift egress ip address feature https://docs.openshift.com/container-platform/4.12/networking/ovn_kubernetes_network_provider/config...  which intends to leverage ip aliases https://cloud.google.com/vpc/docs/alias-ip
This might not be yet supported in all versions of openshift in particular openshift dedicated. Also this approach is likely to not scale to many pods as AFAIK it would require for each namespace min(nb nodes, nb pods) while ip aliases per GCE vm is documented by redhat as "Per node, the maximum number of IP aliases, both IPv4 and IPv6, is 100.". So this approach it likely to not scale in openshift.

I'd be interested to get confirmation that this same setup is also possible with GKE, possibly by proper configuration of IP masquerading

https://cloud.google.com/kubernetes-engine/docs/concepts/ip-masquerade-agent#masquerading_scenarios and use of EgressNATPolicy CR

Then CEL matcher source.ip attribute would be used in rules to restrict destination to a set of namespace IP addresses.

I'd like to hear SWP team opinion about this workaround in particular in openshift.

Thanks in advance.

[ngprabhu-google · Accepted solution]

Hi Guillaume -

1. Regarding Openshift, the workaround you described should work in theory. You would probably need to have a namespace reference a single pod if you want to segment the source per pod, but should then be able to use the "egress IP" in a SWP policy to match the source.
2. Regarding supporting this natively in GKE, we have started discussing this internally, but we don't have a committed timeline yet. 

Thanks,
Naveen

[Gokhan · Accepted solution]

Hello,
we are working on exact same scenario, the difference is, we are considering workload identities. 
If we enable Workload Identity federation, then match GKE Service Accounts, with IAM service accounts, can we make filters for those service accounts?  

[kevinam · Accepted solution]

For GKE service account are managed slightly different.  For VMs service-account information is derided from the Andromeda unique identifier (AEID), for GKE the container/app needs to query the metadata service to receive a token (JWT) which is provided in the HTTP header.

JWT support is on the roadmap.  Please reach out to the SWP PM ngprabhu@ to provide more customer context for prioritization.

[gberche-orange]

Thanks Kevin, is there a related public roadmap url for the JWT support you could share ?

[ngprabhu-google · Accepted solution]

Hi - Unfortunately we do not have a public roadmap that we publish. You can reach out to me directly at ngprabhu@google.com.

[Piotrgrohs · Accepted solution]

@ngprabhu-google  when it will be ? I want use a workload identity and SWP for GKE 🙂   

[Gokhan · Accepted solution]

@ngprabhu-google 
how can I reach to you? 

[ngprabhu-google · Accepted solution]

You can reach out to me at ngprabhu@google.com