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/
Related
I am using a Google Cloud Project to automate the creation of some users inside of our organization. I have been using some API's that are hosted using the Google Cloud and have had no problem authenticating and using the API's, however I am not sure if I should be using a service account for this. I am currently using the Google Drive API, the Google Admin SDK(Directory API), the Sheets API, and the Docs API to create some accounts and manage an error log.
What I am asking is, should I be creating a service account to use the API's or is my own personal Google Workspace account okay for creating these? Is there a site/video/something that can guide me in the right direction if I do need to create a service account. I personally would rather have all of the automation using a service account for authentication, but the only videos and tutorials I found on using the service accounts are trying to use resources pertaining to Cloud Computing and service accounts that are impersonating other service accounts.
Using a Service Account is the best course of action for security reasons when you are the one giving authorization and authentication to your organization.
It is identical to granting access to any other identity to allow a service account access to a resource. For instance, suppose you only want an application that runs on Compute Engine to be able to generate items in Cloud Storage.
As a result, instead of managing each and every one of your users, you may limit and manage service accounts, assign certain roles to specific users or groups, and keep track of them because several service accounts can be created in a project.
Since you use Google Workspaces, I also advise you to read the shared documentation posted in the comments by #John Hanley.
I have googled quite heavily the last couple of hours to see if I could use Google Secret Manager from an external service like AWS Lambda or my local PC. I could not find anything helpful, or something that describes properly the steps to do so.
I do not want to play with the APIs and end up doing the authenticating via OAuth myself, I wish to use the client library. How would I go about doing so?
I have so far referred to the following links:
https://cloud.google.com/secret-manager/docs/configuring-secret-manager - Describes setting up secret manager, and prompts you to set up Google Cloud SDK.
https://cloud.google.com/sdk/docs/initializing - Describes setting up the cloud SDK (doesn't seem like I get some kind of config file that helps me to point my client library to the correct GCP project)
The issue I have is that it doesn't seem like I get access to some form of credential that I can use with the client library that consumes the secret manager service of a particular GCP project. Something like a service account token or a means of authenticating and consuming the service from an external environment.
Any help is appreciated, it just feels like I'm missing something. Or is it simply impossible to do so?
PS: Why am I using GCP secret manager when AWS offers a similar service? The latter is too expensive.
I think that your question applies to all GCP services, there isn't anything that is specific to Secret Manager.
As you mentioned, https://cloud.google.com/docs/authentication/getting-started documents how to create and use a Service Account. But this approach has the downside that now you need to figure out to store the service account key (yet another Secret!)
If you're planning to access GCP Secret Manager from AWS you can consider using: https://cloud.google.com/iam/docs/configuring-workload-identity-federation#aws which uses identity federation to map an AWS service account to a GCP service account, without the need to store an extra Secret somewhere.
I am about to launch a webapp based on subscription. FYI, the web application manages health care data, and my customers are concerned about the security of data in the cloud.
Is there any certificate, or any official information I can give to my customers on the behalf of AWS proving that the data in any storage used by my application will be encrypted?
THANK YOU
From What is AWS Artifact?:
AWS Artifact provides on-demand downloads of AWS security and compliance documents, such as AWS ISO certifications, Payment Card Industry (PCI), and Service Organization Control (SOC) reports. You can submit the security and compliance documents (also known as audit artifacts) to your auditors or regulators to demonstrate the security and compliance of the AWS infrastructure and services that you use. You can also use these documents as guidelines to evaluate your own cloud architecture and assess the effectiveness of your company's internal controls. AWS Artifact provides documents about AWS only. AWS customers are responsible for developing or obtaining documents that demonstrate the security and compliance of their companies.
It explains what AWS does. However, you would also need to prove that you are using the cloud correctly, such as verifying user's identities and not making buckets public.
NO, there is no such a document, you need to apply and obtain this certificate.
AWS is complaint, for there part Security of the cloud, and you are responsible for the Security in the cloud. AWS Artifact is a repository.
AWS Config is the tool you will use to monitor the configuration of
your stack, can repair configurations also.
AWS Cloudwach will monitor the performance, brings you alerts and evoke Lambda
AWS Cloud Trail will monitor the API calls.
AWS Macy to check your buckets for Personal Identifiable information.
Then you are the one who enable encryption and choose the Key management and rotation, AWS KMS.
Just to mention few services to be aware of. Best regards.
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
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.