Never fear, dear internet citizen! You don't have to create a new service, we can fix the existing one!
How? With the power of Identity and Access Management (IAM!) 🦸🏻♀️
What does "Allow unauthenticated invocations" on my Cloud Run service even mean?
Any time you use the Google Cloud Platform console to create a new Cloud Run service (in this case, the suggested gcr.io/cloudrun/hello container) you're presented with this little checkbox:
Image: 'Allow unauthenticated invocations' checkbox from the Cloud Run creation screen.
If you forgot to check this on service creation, you end up getting a lovely HTTP 403 message when you try and navigate to the service URL:
Image: Sad 403 error message if you did not allow unauthenticated invocations.
So what is actually going on here?
Permission to GET
If you take a look at the checkbox's extended help text on service creation, you see this little tip:
This is a shortcut to assign the Cloud Run Invoker role to the
allUsersmember type. You can use IAM to manage access after the service is created.
What this means is essentially what it says: there's one little IAM rule that's added at creation to allow anyone access to the service.
So, if you forgot to check "Allow unauthenticated invocations" at service creation, we can just manually add this role, and fix the service!
But why would you want authenticated invocations in the first place? 🤔
There are many design reasons why you wouldn't want to allow just anyone to access your service, including having only authenticated invocations/users -- or even only GCP components -- access your service. Cloud Run services don't have to be public! 🌈
On the Cloud Run dashboard, you'll see a list of your services. Selecting one will show the service details in the Info Panel on the right hand side of your screen. (Tip: you can hide this panel if you don't need it later by clicking 'Hide Info Panel')
Image: Info panel for the hello-unauthenticated service.
You're going to want to click on [+👤ADD MEMBER] to get to the dialog we want.
Image: Clicking on the Add Member Button.
From there, we see a dialog to allow us to add members to the service.
Image: New member dialog
The new member we want is called allUsers (anyone). We can search for all and the value will appear in a suggested dropdown.
Image: Member dialog suggestions for 'all'
Protip: clicking the (?) will show you a list of other possible choices here, and their meanings.
For the role, we want to add it to the Cloud Run Invoker role (a role that can invoke Cloud Run).
Animated Image: step by step process of adding the Cloud Run Invoker role
With these two options, we are specifying that yes, we want anyone to be able to run our service.
After saving, you can go to the original service URL, and huzzah! It works! The day is saved!
Image: The successful landing page for the gcr.io/cloudrun/hello service.
Not only were we able to recover our missed checkbox at creation time, but we also were able to do it without having to push a new revision of our service! The $K_REVISION value (a helpful environment variable!) shows we are still using hello-unauthenticated-00001, so even if you deploy with the wrong visibility first time, you can fix it and no-one will be able to tell!
Top comments (0)