I want to enable a service account to invoke a Cloud Run service and restrict the invocation to a specific URL (eg.: https://myservice/specific).
Most of GCP resources allow for conditional restrictions using IAM Conditions (like picture below).
I'm wondering if Cloud Run does support IAM Conditions, and I case it does not what's the recommended way to achieve such kind of restriction.
Thanks.
IAM service is a free Google Cloud product that manage IAM access for Google Cloud product.
That being said, go back to your case: You have a service account that you want to restrict (or allow) the access to Cloud Run product. No problem, you can grant the run.invoker role to access to Cloud Run.
If you want finer/inner Cloud Run service permission, you should guess that it is not possible with IAM service. Indeed, the inner permission (or business permission) are specific to your code, and not to the Google Cloud code (i.e. the Google Cloud products).
And IAM Conditions won't help you in that case. IAM Conditions applies on Google Cloud product definition. For instance, you can grant a service account to access to Cloud Run services with the service name starting by something. But again, it's only on Google Cloud product information.
IAM can't help you on that. You could have a look at API Gateway. Or, you should have to implement the checks directly in the /path code to filter the authorized calls.
Based on this link, you can grant your Service Account a "Cloud Run Invoker" role.
You can read this link for more information.
I've tried to add the role "Cloud Run Invoker" to a user and it works. Just try it to a service account.
The service accountIAM permission,you can achieve this while deploying/editing a service you have the option to select "Allow only authenticated requests". This would basically do two things, one is restrict access to users listed within the IAM permissions list of the project. Secondly, you'd be able to give invocation permissions to email addresses and/or email domains Documentation here.As also can be inferred from the documentation here, 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
While there are other options to authenticate to Cloud Run services whose "Require authentication" option is turned on, all of the options issue and use a Google-issued token one way or another. That's because the option "Require authentication" uses IAM to secure Cloud Run services
Related
I am working on a project, that sorts my emails in to folders in Python. I having a #outlook.com email and I am going to be using Microsoft Graph API. First I have just been using cURL to try out the different endpoints.
I have had a few problems, I am trying to get my personal access token, so I can use the endpoint /me/messages I have tried many different ways to authenticate using the documentation, but none of them seem to work. I don't have any active directory, I just want to use my own personal account, which I have selected when creating the project. Since my project is going to be running on the backend, I will be using the Application permissions instead of Delegated permission (please tell me if it is possible to use application permissions with my idea)
It would be helpful, if people could send me the cURL commands, to get my access token and maybe a example request to get my emails. Then I can translate this into Python code. If I receive any errors while executing your commands I will just comment on your answer.
Thanks in advance.
Based on the following documents I do not believe it is possible to use application permissions for a non-interactive (daemon) solution with a Microsoft Account. Only delegated permissions are supported since you as a user will not be able to grant admin consent on your Microsoft Account.
"Daemon applications can be used only with Azure AD organizations. It doesn't make sense to try to use daemon applications to manipulate Microsoft personal accounts. The admin consent will never be granted."
Scenario: Daemon application that calls web APIs
Account type support in authentication flows
I'm trying to implement security to a backoffice CLI tool (NodeJS) that calls a REST api (Java/JAX-RS) for performing database operations etc.
As we're using Azure AD for all our user accounts I'd like to use it for authenticating our users and also for authorization.
The authorization is needed since not all members of the AD is supposed to use the CLI, and there are two types of users of the CLI with a different set of available commands, meaning that even if you are able to use it, some features might be locked out depending if you are an operator or administrator.
I've managed to create two applications in Azure AD, one for the CLI and one for the API. I can login using our AD credentials, fetch Access tokens for the CLI app id requesting the REST API resouce. On the client side I'm using https://www.npmjs.com/package/simple-oauth2 .
On the Java side the tokens are validated against Microsoft public keys, so everything seems to work out fine.
But, how should I lock down the users to either operator or admin roles? One naive way I can think of is to have the user/role correlation in the REST API and only use the OAuth flow for authenticating the user. But I guess that's what the AD is there for... Could OAuth scopes help me in this case?
Or should the REST API call the AD to query for users group memberships, once it receives the access tokens and knows the end user identity?
Thanks in advance!
Use the Application Roles.
Here you will find good description what application roles are and how to handle them:
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
The recommended resources at the end and also very helpful and will guide you through the process.
Also, when developing CLI it is recommended to use the Device Flow - described here with sample code (.net core) here.
I am trying to do Google API authorization through both Web Application approach and service account approach. For web application approach, the quick start code from their website works fine. However when I tried the same code with service account Client ID (same code as the quick start example, just replacing the Client ID), it gives me Invalid_client no registered origin error.
I saw in this post and other SO questions, mostly they forgot to put the Authorized Javascript Origin. However, this is different for service account approach, they don't have this field.
Anyone encountered same issue?
Error message: no registered origin
Request Details proxy=oauth2relay1086088613 immediate=false
scope=https://www.googleapis.com/auth/analytics.readonly
origin=https://localhost:9443 response_type=token
redirect_uri=postmessage state=909080772|0.2369183797
client_id=113356969233986791514 include_granted_scopes=true
Service accounts are typically used in server-to-server communication. You can think of a service account as a robot user that has permissions to access the API. Unless you're doing domain-wide delegation (where a service account can act on behalf of all users on a domain), you probably just want to use OAuth. Perhaps try the credentials wizard and see what it recommends?
If you do end up wanting to use service accounts, you'll need to download a private key for the service account and sign the request with that key (rather than just including the OAuth client ID). To do that, I recommend using one of the Google API Client Libraries.
I'm working on my master where I have to design and prove a solution to expose some university legacy services. None of them have controlled access, so other feature needed is this security layer.
To make this possible I'm using wso2 products: wso2ebs to make some orchestration and messaging transformation; wso2is to connect to a shibboleth idp that already exists; and wso2am to put everything together and expose the services.
I already have the identity provider (Shibboleth) configured on wso2is. I use this http://xacmlinfo.org/2014/12/10/federation-testshib/ to prove it.
To make the authentication layer, I'm not sure but I think that I can use this http://wso2.com/library/articles/2015/03/bring-your-social-identity-to-perform-organizational-authorization-actions-with-wso2-identity-server/ to make the bond between wso2is and wso2am.
But there is a use case I can't solve: wso2am give me an oauth like environment to expose my private services, but how can a student (end user) manage is authorisations? I as a student which use a mobile app that consume information given by an api exposed by wso2am, want to revoke this this authorisations given previously to this mobile app. How can I do this?
TLDR:
If wso2am use an oauth like environment to expose apis, is there a way to the end user revoke an authorisation given previously to an mobile app that make use of an api exposed by wso2apim?
There are two options
If you have client_id, Secret and access token on your hand you can use https://docs.wso2.com/display/AM190/Token+API revoking access tokens part
If not you can use revokeAuthzForAppsByResoureOwner operation in OAuthAdminService
I'm making an application wich allows the admin to manage the files of users in the google apps domain.
Since the docList api is deprecated I used the Drive api.
How I can create a Drive service as another user while logged in as admin?
Some people suggested to use the OAuth consumer key.
But I don't know how to implement this with oauth-2.0.
You might want to check out this post: Google Drive service account returns 403 usageLimits
I used OAuth2 and a service account to accomplish pretty much the same. Keep in mind you need to use the API Console to setup your environment and ensure the service account is added to the Google Apps domain with the proper scopes to allow access.