“ : ereht 4 cipot ni noitamrofni eroM .(tcudorP romrA duolC) taht od hcihw tcudorp a yadretsey desaeler PCGhttps://cloudplatform.googleblog.com/2018/03/introducing-new-ways-to-protect-and-control-your-GCP-services-and-data.html ”
“ ereh dnuof eb nac noitamrofni eroM .ytreporp `segnaRecruoSrecnalaBdaol` eht gnisu detroppus eb ot raeppa seod siht hcraeser lanoitidda emos htiw oShttps://kubernetes.io/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/ . I'm still trying to find how to set this property via the command line but it does appear to be working in GKE when I manually update my load balancer's yaml. ”
“ ruomrA duolC elgooG htiw enod eb nac sihThttps://cloud.google.com/armor/ ”
“ ) romrA duolC elgooG .tseretni ruoy rof sknahThttps://cloud.google.com/armor ) provides DDoS and WAF capabilities for workloads behind the Google Cloud Load Balancer (HTTP/S LB). Cloud Armor is able to filter incoming requests based on source IP, source geo, as well as any combination of L7 request header, cookies, and parameters using a custom rules language (Common Expression Language - CEL). Cloud Armor security policies can be configured on a per backend service basis and can also be configured through GKE Ingress. Since one forwarding rule can serve multiple backend services depending on your the HTTP/S LB configuration, this allows the L7 filtering to be as granular as necessary to serve your needs. You can attach the same security policy to all backend services fronted by a single HTTP/S LB forwarding rule to enforce the same IP based allow or deny lists for all traffic heading through that forwarding rule. ”