How to add new member to Google Cloud? - google-cloud-platform

When I tried to add new member to GCP it gives me following error..?
Can we access GCP with Microsoft account..? Or how can we add Microsoft acc to GCP?

There's the correct answer (and similar):
Azure AD provisioning and SSO
And there's a hacky (!?) be very careful with this answer:
Google Account with a non-Google email address
Please do not even consider the hacky answer unless this is a one-off and the Microsoft account is a personal account.
Google Cloud Platform only accepts Google accounts.
The federation mechanism creates proxy-like Google accounts for the Azure AD accounts and maintains the mapping for you.
The Google Account with a non-Google email address mechanism creates a Google Account (I strongly encourage you to also use a different password for the Google and Microsoft accounts even though they appear to be the same they are entirely different accounts).
If you use the hacky solution, it will create problems if you subsequently try the correct solution though Google Cloud Support may be able to help you delete the Google "shadow" account to help.
NOTE Many years ago, the only way to use non-Google accounts with GCP was the hacky solution outlined above. Once the federation solutions became available, the hacky solution has become strongly discouraged.

Related

Changing e-mail out of Google but keep on using GCP

Our company uses different Google services (one of them being GCP). We are going to move our e-mail accounts to another mail supplier and we are wondering what the impact will be on the existing GCP services that certain users use. To make it clear our #companyname.com mails are currently hosted by Google and they will be moved to another supplier.
Will the users (identified by their e-mail address) keep on working "seamlessly" with GCP even we do not use Google's mail anymore?
Thanks in advance.
Posting this community wiki answer for better usability.
John Hanley wrote:
If you are using Google Workplace for email and for Google Cloud IAM, you will NOT be able to move those identities to another email platform without keeping the Workplace account. The authentication must be handled by a Google account (Gmail, Workplace, Identity Platform).
You can move your email (send/receive) to another platform. It is the authentication/authorization part that must stay with Google. You can have email for your domain hosted by another provider and still keep Google Workplace. Otherwise, you will need to create new Gmail or Identity Platform identities for Google Cloud IAM.

How to resolve GCloud permissions?

I am trying to publish my Android app to our company's Play Store.
On Google API access page
I am trying to create new service account. It does not work.
You are missing at least one of the following required permissions:
Project
orgpolicy.policy.get resourcemanager.projects.get Check that the
folder, organization, and project IDs are valid and you have
permissions to access them
My GCP shows myname#github.com google account.
On the other side,Google API(Google Play Console) shows MYCOMPNAY Team account.
How to solve this IAM problem?
I'll do my best to answer but the question lacks some detail.
As the error describes, service accounts are a distinct type of credential used by Google that are intended to be used by software (rather than humans) for interacting with Google services. It makes some sense (though I'm unfamiliar with the Play process) that you'd need to use service accounts rather than human accounts with this service.
Unlike, regular (human) accounts (e.g. yourname#github.com), service accounts are owned by Google projects. When you create a service account, you'll need to scope the account to an existing Google project.
Google provides various Consoles for different services. I'm most familiar with Google Cloud Platform (GCP) and so I would create projects and service accounts using GCP's CLI (Cloud SDK aka gcloud) or https://console.cloud.google.com. Are you using something similar?
Unfortunately, I think, Google's tools scope projects (even though these are universal Google resources) to specific platforms (Cloud, Firebase, Apps etc.) and so you may not be able to see all your projects via the e.g. Cloud Console.
So....
If you have a Play (!?) Console, there should be a mechanism to list|create projects. If you haven't already, created a project to own your service account. Then the tool should provide a mechanism to create a service account. Do so under that projects. Lastly, you'll need to grant the service account permissions so that it can do what you need it to do (e.g. publish your app).
If you add more details to your question, I may be able to help.
NOTE One distinction between human (e.g. yourname#github.com as a Google account) and a service account is that human accounts using 3-legged OAuth while service accounts use 2-legged OAuth. This is because the service account is not able to interact with OAuth prompts as a human user would and it is often a good "tell" when you need to use a human vs. a service account.
See:
Google Play: (API) Projects and Service Accounts
Understanding Service Accounts
Using OAuth for Server-to-Server apps

Using Google OAuth2 and OpenId Connect in a mixed environment (GCP apps and on-premise)

Migrating on-premise services and applications to Google Cloud Platform and during an extended transition will be in a blended GCP, on-Prem, third party service provided platform. Looking to standardize on GCP OAuth2 provider with the OpenIdentity provider as single source of authentication and verification.
I have poured over the documentation provided by Google Identity Platform and I see Authorization As a Service which appears to be based on Firebase and is close to what I need/want but not exactly.
The Open Identity provider has an SDK and can be integrated with Web, Server, and mobile device applications. Good!
What I am looking to confirm is that I can also use the OAuth2 SDK to authenticate a user with a token, and then use that token with the OpenIdentity APIs to control user access and features. I know this is entirely possible for the GCP native applications.
Presently it looks like using SAML to integrate with another OAuth2 platform within the Identity Product and then enabling the OpenIdentity provider will meet "most" of my needs. What would be missing would be standardizing on the Google Identity Platform before we migrate all our products and services onto GCP.
The burning question, can I use the OAuth2 implementation with services and apps not hosted on GCP?
The documentation seems to suggest to me yes and no simultaneously.
Any help appreciated at his point.
See Hanley's response above. I had read the documentation available for several identity related products for Google Cloud Platform.
My question made sense to me but it does not translate to those who actually understand the the Identity Platform itself, and even say just one (1) of the integration implementation methods. Reading through the developer docs I caught upon a really important piece of perspective that answered nearly all of my questions.
In case it is helpful:
- Google Sign-in uses #gmail.com (or others) google identities which applications or organizations can leverage
- One can configure, create, import domain user identities using the Google Admin console
- These are both considered domain entities and one can configure single sign-on (OAuth, SAML, 509x, JWT, OICD) for these by using providers, or writing custom providers
- Either permits organizations and projects to utilize IAM and other Security-Identity features within GCP out of the box with minimal overhead
This covers about 90% of my initial use case and once I understood that domain user identities are either Google, or your own private domain identities created through the Admin Console through Group and User management, the remaining 10% was easy enough to solve.
I'm going to stop commenting here as this was key in understanding why things did not make sense, and why Mr. Hanley (thank you for your patience) was unable to answer my question at the beginning.
Hoping this helps someone else.

How can I create a user in Google Cloud Platform without having to create a new Gmail user?

I want to create a user account for contacting developers using their own email addresses, not a new Gmail user in my account. Google Cloud Platform seems to let me create the users, but they never receive an email and hence can't complete the account creation.
As it happens, they are Google Docs users with their own Google accounts, but naturally they'd rather not have yet another email address. Is this even possible or does Google tie Google Cloud Platform into Google Docs? It seems a major limitation of Google Cloud Platform if they do.
Google Cloud Platform, G Suite (formerly "Google Docs") and all other Google services share an identity system. The identity system requires humans to have user accounts while software|machines have service accounts. One Google user account equals one user.
There are 2 flavors of (Google) user accounts: [your-name]#gmail.com and those created by an organization for its users someone#acme.com. For example, Google uses Google identity internally and so Googlers have emails [their-name]#google.com.
When you create a Google Cloud Platform project, anyone with a Google account may be added to it. Whether their Google account is something#gmail.com or an account created by their employer for them.
The only time your users will receive an email from you when you add them to a Google Cloud Platform project is if you make them project owners. This is because, ownership requires acceptance of Google's Terms of Service. Other types of users will be added without receiving an email (from Google about it) but will be able to access your project's resources.
I suspect your users have been added correctly and you're ready to go!
the most simple is to share a directory with those off-domain email addresses
this is possible, because Google Docs is backed by Google Drive as storage.
setting them up with IAM would only add complexity, which is not required
(at least, unless you won't have to grant them access to GCP resources).

AWS assume iam roles vs gcp's json files with private keys

One thing I dislike about Google Cloud Platform (GCP) is its less baked-in security model around roles/service accounts.
Running locally on my laptop, I need to use the service account's key specified in a JSON file. In AWS, I can just assume a role I have been granted access to assume (without needing to carry around a private key). Is there an analogue to this with GCP?
I am going to try and answer this. I have the AWS Security Specialty (8 AWS certifications) and I know AWS very well. I have been investing a lot of time this year mastering Google Cloud with a focus on authorization and security. I am also an MVP Security for Alibaba Cloud.
AWS has a focus on security and security features that I both admire and appreciate. However, unless you really spend the time to understand all the little details, it is easy to implement poor/broken security in AWS. I can also say the same about Google security. Google has excellent security built into Google Cloud Platform. Google just does it differently and also requires a lot of time to understand all the little features / details.
In AWS, you cannot just assume a role. You need an AWS Access Key first or be authenticated via a service role. Then you can call STS to assume a role. Both AWS and Google make this easy with AWS Access Keys / Google Service Accounts. Whereas AWS uses roles, Google uses roles/scopes. The end result is good in either platform.
Google authentication is based upon OAuth 2.0. AWS authentication is based upon Access Key / Secret Key. Both have their strengths and weaknesses. Both can be either easy to implement (if you understand them well) or a pain to get correct.
The major cloud providers (AWS, Azure, Alibaba, Google, IBM) are moving very fast with a constant stream of new features and services. Each one has strengths and weaknesses. Today, there is no platform that offers all the features of the others. AWS today is ahead both in features and market share. Google has a vast number of services that outnumber AWS and I don't know why this is overlooked. The other platforms are catching up quickly and today, you can implement enterprise class solutions and security with any of the cloud platforms.
Today, we would not choose only Microsoft or only Open Source for our application and server infrastructure. In 2019, we will not be chosing only AWS or only Google, etc. for our cloud infrastructure. We will mix and match the best services from each platform for our needs.
As described in the Getting Started with Authentication [1] page, for service accounts it is needed the key file in order to authenticate.
From [2]: You can authenticate to a Google Cloud Platform (GCP) API using service accounts or user accounts, and for APIs that don't require authentication, you can use API keys.
Service and user accounts needs the key file to authenticate. Taking this information into account, there is no manner to locally authenticate without using a key file.
Links:
[1] https://cloud.google.com/docs/authentication/getting-started
[2] https://cloud.google.com/docs/authentication/