How do I restrict GCP load balancer access by domain, domain's IP or GKE ingress IP?

Viewed 29

I have assets in a Google Cloud Storage bucket. I created a subdomain (aaa.bbb.com) and a load balancer using that subdomain to point to that bucket (e.g. aaa.bbb.com/image-to-read.png). I also have an application using Google Kubernetes Engine. The goal is to make sure all users are blocked except that application on GKE. And all the GKE application is doing is reading the url of the assets to display them. How do I achieve that?

Things I've tried:

  1. Setting GCS cors for the bucket

    It turns out this only restricts by domain if people are signed into Google with the domain.

  2. Workload Identity

    This has just not worked for me. I also have an API service in the same GKE cluster that uses this and I'm able to upload fine with it. However, using a plain <img /> tag with the source as a the GCS bucket ignores the Workload Identity as far as I can tell.

  3. Cloud Armor

    This seems the most promising. I have successfully restricted by IP address but, unfortunately, the only IP address I'm able to restrict by is my actual local computer. I believe that means the request headers are sending my computer's IP address to the load balancer. But what I am trying to do is restrict access by the application's load balancer IP address or even by the origin domain (preferred).

What I'm asking is probably a basic networking question, but I'm no wiz at all the devops/infrastructure concepts so any help would be appreciated. Thanks!

1 Answers

You have two options:

  • Cloud Storage authorization
  • Deploy an HTTP(S) Load Balancer + Cloud Armor.

I am not sure what you mean by GKE ingress IP.

The simplest is to add Authorization in your GKE application when accessing Cloud Storage.

Authorization:

  • Service Account OAuth Access Token
  • Signed URLs.

Both methods are easy to implement.

Note: Workload Identity Federation also generates service account OAuth access tokens. Use that method if need to federate credentials from one OAuth Authority to Google. However, for a GKE application, Signed URLs or service account OAuth access tokens are probably the correct solution.

Related