How to invoke a Cloud Run app without having to add the Authorization Token - google-cloud-run

I have a cloud run app deployed that is for internal use only.
Therefore only users of our cluster should have access to it.
I added the permission for allAuthenticated members giving them the role Cloud Run Invoker.
The problem is that those users (including me) now have to add authorization bearer header everytime I want to access that app.
This is what Cloud Run suggests to do (somehow useless when u wanna simply visit a frontend app)
curl -H \
"Authorization: Bearer $(gcloud auth print-identity-token)" \
https://importer-controlroom-frontend-xl23p3zuiq-ew.a.run.app
I wonder why it is not possible to be realized as authorized member like the GCP figures out. I can access the cluster but have to add the authorization header to access the cloud run app as authorized member? I find this very inconvenient.
Is there any way to make it way more fun to access the deployed cloud run app?
PS: I do not want to place the app in our cluser - so only fully managed is an option here

You currently can't do that without the Authorization header on Cloud Run.
allAuthenticated subject means any Google user (or service account), so you need to add the identity-token to prove you're one.
If you want to make your application public, read this doc.
But this is a timely request! I am currently running an experiment that lets you make requests to http://hello and automatically get routed to the full domain + automatically get the Authorization header injected! (This is for communication between Cloud Run applications.)

GCP now offers a proxy tool for making this easier, although it's in beta as of writing this.
It's part of the gcloud suite, you can run:
gcloud beta run services proxy $servicename --project $project --region $region
It will launch a webserver on localhost:8080, that forwards all requests to the targeted service, injecting the user's GCP token into all requests.
Of course this can only be used locally.

Related

Programmatically check if Cloud Run domain mapping has done

I'm developing a service which will have a subdomain for each customer. So far I've set a DNS rule on Google Domains as
* | CNAME | 3600 | ghs.googlehosted.com.
and then I add the mapping for each subdomain in the Cloud Run console. I want to do all this programmatically everytime a new user registers.
The DNS rule will handle automatically any new subdomain, and to map it to the service I'll use the gcloud command:
gcloud beta run domain-mappings create --service frontend --domain sub.domain.com
Now, how can I check when the Cloud Run provisioning has done so that I can notify the customer that the platform is ready to use? I could CRON every minute the command gcloud beta run domain-mappings describe --domain sub.domain.com, parse the JSON output and check if the status has done. It's expensive, but it should work.
The problem is that even if the gcloud cli or the web console mark the provisioning as done, the platform isn't reachable for another 5-10 minutes, resulting in a ERR_CONNECTION_REFUSED error. The service logs show that a request to the subdomain is being made, but somehow it won't serve it.
I ended up using a load balancer as suggested. I followed this doc "Setting up a load balancer with Cloud Run, App Engine, or Cloud Functions", the only different thing is that I provided my own wildcard certificate (thanks to Let's Encrypt and certbox).
Now I can just use the Google Domains' API to instantly create a subdomain.

Cloud Scheduler has Permission Denied when attempting to run a Cloud Run job

I have created a simple Cloud Run job. I am able to trigger this code via a curl command:
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://sync-<magic>.a.run.app
(Obviously <magic> is actually something else)
Cloud Run is configured for Ingress to Allow All Traffic and with Authentication to be required.
I followed this documentation: https://cloud.google.com/run/docs/triggering/using-scheduler
And created a service account, granted it the Cloud Run Invoker Role and then setup an HTTP scheduled job to GET the same URL I tested with CURL. I have Add OIDC Token selected, and I provide the service account created above and the Audience which is the same URL I used with curl.
When I attempt to trigger this job (or when it triggers based of the native cron) it fails with:
{ "status": "PERMISSION_DENIED", "#type": "type.googleapis.com/google.cloud.scheduler.logging.AttemptFinished", "targetType": "HTTP", "jobName": "projects/<project>/locations/<region>/jobs/sync", "url": "https://sync-<magic>.a.run.app/" }
Again <project>, <region> and <magic> have real values.
I tried using service-YOUR_PROJECT_NUMBER#gcp-sa-cloudscheduler.iam.gserviceaccount.com with YOUR_PROJECT_NUMBER updated appropriately as the service account that runs the scheduled job. It has the same error.
Any advice on how to debug this would be greatly appreciated!
Here is what i did which solved the issue altogether and now I get the success flag when running a secure Cloud Run service via a Cloud Scheduler job -
Create your service on Cloud run - let's call it "hello" and make it secured by removing "allUsers" permission from the list of Permissions PRINCIPALS - you should get an error when going to the endpoint as such - Error: Forbidden
Your client does not have permission to get URL / from this server.
Create an IAM service account for cloud scheduler - let's call it "cloud-scheduler" you will get this: cloud-scheduler#project-ID.iam.gserviceaccount.com now comes the important part :
Give your SA the ability to run Scheduler Jobs by adding the -
Cloud Run Invoker & Cloud Scheduler Job Runner permissions
Create your Cloud scheduler job and add the new SA to it according to google procedure :
Auth header: Add OIDC token
Service account: cloud-scheduler#project-id.iam.gserviceaccount.com
Audience : https://Service.url.from.cloud.run.service/
Add to your cloud run service an additional principal that will let your SA access to cloud run invoker
Run your scheduler and voila - all green !
Enjoy
I have tried to create a new service account, gave it Cloud run invoker role. Disable the Cloud Scheduler API and re-enable it.
The only thing that work for me is changing Auth header from Add OIDC token to None.
For some reason Cloud Scheduler change None back to Add OIDC token and Trigger cloud run normally

How to authorize Google API inside of Docker

I am running an application inside of Docker that requires me to leverage google-bigquery. When I run it outside of Docker, I just have to go to the link below (redacted) and authorize. However, the link doesn't work when I copy-paste it from the Docker terminal. I have tried port mapping as well and no luck either.
Code:
credentials = service_account.Credentials.from_service_account_file(
key_path, scopes=["https://www.googleapis.com/auth/cloud-platform"],
)
# Make clients.
client = bigquery.Client(credentials=credentials, project=credentials.project_id,)
Response:
requests_oauthlib.oauth2_session - DEBUG - Generated new state
Please visit this URL to authorize this application:
Please see the available solutions on this page, it's constantly updated.
gcloud credential helper
Standalone Docker credential helper
Access token
Service account key
In short you need to use a service account key file. Make sure you either use a Secret Manager, or you just issue a service account key file for the purpose of the Docker image.
You need to place the service account key file into the Docker container either at build or runtime.

Jitsi Docker server JWT authentication does not work. Why?

I am trying to enable jwt authentication for my self-hosted (Docker) Jitsi server. There is a guide on self hosting with Docker and on that guide, it tells how to enable authentication. This is the guide: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker
Now I will copy and paste the autentication part from that guide so that you can see it more clearly.
Authentication can be controlled with the environment
variables below. If guest access is enabled, unauthenticated users
will need to wait until a user authenticates before they can join a
room. If guest access is not enabled, every user will need to
authenticate before they can join.
Authentication using JWT tokens You can use JWT tokens to authenticate
users. To enable it you have to enable authentication with ENABLE_AUTH
and set AUTH_TYPE to jwt...
After these instructions, I changed my .env file. I did the configurations told above. Then I did docker-compose down. Then I removed the ~/.jitsi-meet-cfg and then created again with mkdir. Then I ran the command docker-compose up -d.
Then to try it, I am entering the URL:
https://{ip_add}:8443/room?jwt=randomwords
I am connecting to the server remotely thus I am accessing it with an ip. And because I did not provide a token, I should not be able to create/join to a meeting but I am able to. Whatever I write to the url I still can join.
Can someone help?

Hyperledger Composer Multiple user mode for REST server throws 401 error

I have been following the tutorials which are provided in Hyperledger Composer docs, but I am not getting the results that they are supposed to I should be getting. Specifically, when I try to enable the multiple user mode for the REST server and I try to call one of the business network REST API operations using the REST API explorer I always get a HTTP 401 Authorization Required. According to the Tutorial, I if get this error is due to I have not authenticated correctly to the REST API, but it does not mention why this error occurs or how I may fix it.
It is very important for application development to be able to authenticate each user who wants to make requests to the API.
What version of Hyperledger Composer are you using?
The tutorial/document you refer to is correct for v0.15.0 and works a little differently for prior versions.
Are you seeing an Access token at the top of the Browser Window - this indicates that you have successfully authenticated and can continue with the steps for the Wallet.
If you are not seeing an Access token displayed, then make sure you hit your REST server with a URL similar to http://localhost:3000/auth/github again and login.
If you are still experiencing problems I would suggest going back to just using authentication without multiuser mode and verify that the authentication works properly from there.
After some research, I found a solution and worked for me.
If you already enable Github authentication then ignore. Otherwise first enable authentication following this tutorial Enaling Authentication.
Before start rest server you will export your admin card from the network by using this command:
composer card export -n admin#sample-network -f admincard.card
Now start rest server with authentication using this command:
composer-rest-server -c admin#sample-network -p 3000 -a true -m true
After some time rest server will start.
Now First, go this link for authentication: http://localhost:3000/auth/github
After successful authentication, you will get an access token and also you will see a Wallet options below.
Now you need to import a card that you already export from your network.
That's it, you can able to add anything to your network.
In my case, I have two missed steps:
enabling authentication for the REST server
https://hyperledger.github.io/composer/v0.19/integrating/enabling-rest-authentication.html
composer-rest-server -c admin#you_project -a true, I just execute composer-rest-server but did not specify the identity "admin#you_project" before.

Resources