HTTP cloud scheduler job fails to trigger cloud run even with oidc service account authentication - google-cloud-platform

HTTP cloud scheduler job fails to trigger cloud run endpoint. Created a service account and its provided with cloud scheduler and cloud run admin roles. On cloud run permissions tab the account is given cloud run invoker permission. The cloud run endpoint can be triggered on console and returns successfully. The cloud scheduler job is getting created if no authentication is required and when it sends a request cloud run returns 403 HTTP response. Command used is
gcloud beta scheduler jobs create http *job_name* --schedule="* * * * *" --uri="https://*cloud-run-app-name-*cno4ptsl2q-ew.a.run.app" --http-method=GET --oidc-service-account-email="*project_id_number*#cloudservices.gserviceaccount.com"
On Console when this command is run invalid argument error occurs. When I do it on console creating job failed Unknown Error

OIDC
needs the url in the AUD param, make sure you have it.
best would be to use OAUTH
OAUTH
you need only the service account and scope https://www.googleapis.com/auth/cloud-platform

When you use OIDC authentication, you must specify "OIDC Audience" in your command if you didn't specify in URI.
Refer here to get more info about Cloud scheduler's OIDC audience flag.
It seems that your URI didn't include audience value.
Check attached link and retry creation job after add audience flag in your command.
This is my command which successed to create Cloud scheduler job
gcloud scheduler jobs create http deax-tweets-collection --schedule='* * * * *' \ --uri='https://job-name-cno4ptsl2q-ew.a.run.app' --http-method='GET' \ --oidc-service-account-email='XXXXX#project-id.iam.gserviceaccount.com' \ --oidc-token-audience='https://job-name-cno4ptsl2q-ew.a.run.app'

Related

Cloud Composer Service Account Scope For Running Services within GCP

I am setting up a DAG in Cloud Composer that triggers a number of Cloud Run and Cloud Function services. The service account specified in the Cloud Composer Environment (a user created SA) definitely has permissions to invoke both Cloud Run and Cloud Function services, however the Cloud Run functions are giving the following error:
The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header. Read more at https://cloud.google.com/run/docs/securing/authenticating
The tasks are like so:
#t1 as request first report
big3_request = SimpleHttpOperator(
task_id= "big3_request",
method='GET',
http_conn_id='trigger_cloud_run_service_conversions_big_3',
endpoint='',
response_check = lambda response: True if response == ("ok", 200) else False
)
I would have thought that the cloud composer environment would be able to use the service accounts IAM roles, but this doesn't seem to be the case. What do I need to do here to enable the services to run? It looks like I can add the keyfile of the service account to the connection, but I don't see why this should be necessary if the same service account is used in the CC environment?
Your service (your SimpleHttpOperator task running in cloud composer) needs to provide authentication credentials in the request. More precisely it needs to
add a Google-signed OpenID Connect ID token as part of the request
You can find here in the official Google doc, different methods to provide such token and a proper request to your Cloud Run service endpoint.

How to configure a Cloud Scheduler job to call a Cloud Run endpoint that allows unauthenticated calls

I have a Cloud Run service setup and I have a Cloud Scheduler job that calls an endpoint on that service.
The job sent a GET call (which have an header with a jwt and an api-key, necessary to certify the call to the endpoint) to the Cloud Run endpoint. I have already tried to test the endpoint locally, and it works. Maybe it is necessary a particular configuration for the scheduler to work?
When the job work, I can see from the log console on Cloud Run this:
Cloud Run Console Log.
What can I do to fix this problem?
Thank you
You can follow these docs which walk you through creating or editing a service account for the Scheduler Job to use which is allowed to 'invoke' Cloud Run services.
Thanks,
Josh

Access a cloud run from another cloud run

I am developing an application where i have hosted the frontend in cloud run: public access, no authentication
Another cloud run service has the backend. This requires authentication and is not open to public.
Ofcourse, if I disable authentication on backend service, everything works smoothly.
Is it possible to access the backend with authentication enabled from the frontend cloud run service?
Both the services are in the same serverless VPC.
As captured in the official doc, frontend can securely and privately invoke backend by leveraging the Invoker IAM role:
Grant the service account of frontend the Cloud Run Invoker IAM role.
When you issue request from frontend to backend, you must attach an identity token to the request, see here for code examples
To connect two Cloud Run applications privately, you need to obtain an identity token, and add it to the Authorization header of the outbound request of the target service. You can find documentation and examples here.
For Cloud Run service A (running with service account SA1) to be able to connect to private Cloud Run service B, you need to:
Update IAM permissions of service B to give SA1 Cloud Run Invoker role (roles/run.invoker).
Obtain an identity token (JWT) from metadata service:
curl -H "metadata-flavor: Google" \
http://metadata/instance/service-accounts/default/identity?audience=URL
where URL is the URL of service B (i.e. https://*.run.app).
Add header Authentication: Bearer where is the response obtained in the previous command.

How to print the error codes during authentication of google cloud platform using service account?

I am using google cloud storage and bigquery services of google cloud platform. I'm using service account to authenticate my application and cloud sdk to perform any actions on them.As of now, I'm able to connect and also able to perform any actions. I am curious to know that let suppose if my service account file get modified or somehow the path of that file get lost. Is there is anyway to verify my service account whether it is valid account or not and based on that I can print my code(error codes) and take action on that?
Using Google Cloud SDK commands, you can request additional debugging information:
Google Cloud gcloud has two flags that give user control over information that are displayed:
--log-http Logs all HTTP server requests
--verbosity Can display error or critical`
Cloud Storage gsutil has two options:
-D requests additional debug information
-DD requests full HTTP upstream payload
However, to have greater control over processes and errors, use Google Cloud Client Libraries, to authenticate and access Cloud Storage.

How to modify Google Cloud Pub/Sub subscription acknowledgement deadline for background Cloud Function

When deploying a background Cloud Function for Cloud Pub/Sub via:
gcloud functions deploy function_name --runtime python37 --trigger-topic some_topic
A subscription gets automatically created with a push endpoint (likely App Engine standard endpoint, but those are claimed to be without the need of
domain verification https://cloud.google.com/pubsub/docs/push#other-endpoints).
For the generated subscription/endpoint there doesn't seem like a way to register/verify the domain
(https://www.google.com/webmasters/verification, https://console.cloud.google.com/apis/credentials/domainverification)
As a result the user cannot alter the subscription, for instance:
gcloud alpha pubsub subscriptions update some_subscription --ack-deadline=10
Would yield something like "INVALID_ARGUMENT: The supplied HTTP URL is not registered in the subscription's parent project"
Doing it via the web interface on GCP would also yield an error: "pubsub error INVALID_ARGUMENT"
When connecting to a Cloud Pub/Sub topic via Cloud Functions, a subscription is created on your behalf. This subscription is managed by Cloud Functions and therefore it is not possible to update the acknowledgement deadline.