What i'm asking is if is possible (or nonsense) adding a service account as a Google Cloud IoT registry as a device. Actually i'm using a google library and the service account authentication flow to use the library eg. #google-coud/pubsub to push message to a pubsub topic defined into Google IoT Core registry ... but i cannot handle the app where the library is used as a device of the registry too! I've tried to create a device into Google Cloud IoT core with the public key of the service account but i cannot see heartbeat and telemetry event received ... of course because the service account is not seen as IoT device ...
Related
AWS IoT rules have an https event that can use sigV4 auth, and GCS api allows uploads using sigV4. I have no clue how to configure the rule event to properly authenticate using that though, is it even possible?
I need to allow Cloud Scheduler to call a REST endpoint in an App Engine app in the same project. I have set the scheduler target to "App Engine HTTP" and put the correct service and path to the API. When I test access to it, I am receiving a 401 Unauthorized. This occurs due to the presence of the OpenAPI cloud endpoints service on the API. I have service accounts listed in my OpenAPI yaml that are permitted to access the API, but I am not sure how to allow the Cloud Scheduler through. I have not found any documentation so far that provides this information.
You want to send and consume Cloud Pub/Sub messages from your App Engine application. The Cloud Pub/Sub API is currently disabled. You will use a service account to authenticate your application to the API. You want to make sure your application can use Cloud Pub/Sub. What should
you do?
A. Enable the Cloud Pub/Sub API in the API Library on the GCP Console.
B. Rely on the automatic enablement of the Cloud Pub/Sub API when the Service Account accesses it.
C. Use Deployment Manager to deploy your application. Rely on the automatic enablement of all APIs used by the application being deployed.
D. Grant the App Engine Default service account the role of Cloud Pub/Sub Admin. Have your application enable the API on the first connection to Cloud Pub/Sub.
I realized that if I build an app that uses pubsub. it works without manually enabled the pubsub api. But I couldn't find anything in the documentation about that. Which is the correct answer?
You want to send and consume Cloud Pub/Sub messages from your App
Engine application. The Cloud Pub/Sub API is currently disabled. You
will use a service account to authenticate your application to the
API. You want to make sure your application can use Cloud Pub/Sub.
What should you do?
Let's analyze each possible answer to determine the best answer.
A. Enable the Cloud Pub/Sub API in the API Library on the GCP Console.
This is a possible answer. The standard method is to enable services in the Google Cloud Console. You can also enable services with the Cloud SDK CLI gcloud services enable pubsub.googleapis.com
B. Rely on the automatic enablement of the Cloud Pub/Sub API when the
Service Account accesses it.
This is not a possible answer. Google Cloud Services are not automatically enabled when the service account accesses it. First, service accounts do not access APIs. Service accounts are used to obtain an OAuth Access Token (or Identity Token). These tokens are used to authorize APIs. Services are not automatically enabled with an API makes first access.
C. Use Deployment Manager to deploy your application. Rely on the
automatic enablement of all APIs used by the application being
deployed.
This is not a possible answer. Deployment Manager does not automatically enable services. You can use Deployment Manager Resource Types to enable services. You must create a virtual resource for each API that you want enabled.
D. Grant the App Engine Default service account the role of Cloud
Pub/Sub Admin. Have your application enable the API on the first
connection to Cloud Pub/Sub.
This is not a possible answer. Cloud Pub/Sub Admin does not have permissions to enable services. To enable services the service account (or User Account) will need roles/serviceusage.serviceUsageAdmin or another role with the permission serviceusage.services.enable.
Drumroll Please ....
Therefore the best answer is A in my opinion.
I'm trying to find a way to secure my google cloud app engine standard environment endpoint subscribed to a push pub/sub topic triggered by the creation of a file on google cloud storage.
Since it's only possible to set IP address to the firewall rules of app engine and pub/sub doesn't have a predefined set of IP address it's not possible to use this feature. It's also not possible to use a custom header on pub/sub call and check its validity on the app engine since I have no control over the pub/sub request.
Any suggestion on how to secure the app engine endpoint?
Thanks
Cloud Pub/Sub push does not play well with IP based firewall rules. Making your push notification security based on IP addresses is not the most efficient way.
OAuth and Service Accounts can useful to authenticate access to Google products, such as Cloud Pub/Sub. This will prevent outsiders from accessing your Pub/Sub API for as long as they are not included under a specific service account.
Additionally, in order for your push notifications to be secured, I would follow either of these two solutions:
To confirm that the push notification originates from Cloud Pub/Sub. You could configure endpoints which only accept messages that contain a secret token.
Set up your own push proxy. A simple stateless service might pull messages from Pub/Sub and push them from a fixed IP address to your webhook. Pub/Sub offers value in this setup by providing scaling and availability.
Additionally, I'm not sure if you already implemented exactly this and did not work, but this link from another Stackoverflow issue may be helpful
We have an App Engine application build in Python using Endpoints. Access to it is restricted.
We have software that connects with the App Engine using a service account. With this service account we can also access Google Cloud Storage to create buckets.
Now we want to allow access to the App Engine (and not the Cloud Storage) for specific clients who will write their own software. So their software will be their end-user.
What do we have to create and share with the client so their software can authenticate only with the App Engine?
A service account does not seem possible since this allows access to the Cloud Storage.