I could see SSO for different organisations but, I could not see SSO between 2 GCP organisations/domains/accounts.
SSO between 2 different GCP domains
SSO between primary domain and secondary/sub-domain.
Thank you!
I could see SSO between 2 organisations but not with a single one.
To be more clear how to setup SSO between 2 GCP cloud identities; I.e service provider and identity provider.
Related
We have a scenario like this:
We got 2 domains from GCP and one primary and another one is new sub-domain and all the users were created in Azure AD.
I would like to how users will be synced with when both domains have same users and need access to multiple apps.
2 domains same users but need single access to different apps and users are created in Azure AD.
2 domains same users but need single access to different apps and users are created in Azure AD
Take a look at Workforce Identity Federation:
Workforce identity federation lets you use an external identity
provider (IdP) to authenticate and authorize a workforce—a group of
users, such as employees, partners, and contractors—using IAM, so that
the users can access Google Cloud services.
To configure Workforce Identity Federation with Azure Identity Provider check here.
My goal is to use Okta SSO integrated with AWS SSO to integrate all user Sign-in and permission management for AWS resources from the Okta, using accounts configured on Okta.
I also want it so that each user on Okta has their own Amazon Workspace Windows instance using their Okta credentials.
I currently have a Simple AD (Directory Service) configured on the AWS account, exclusively for Amazon Workspaces access.
Is this a possible goal that can be achieved using OKta, AWS SSO and Directory Service? After going through each of their documentations I am still not clear if these services have the capability to integrate this way.
Any Advice would be appreciated.
There are two topics in this question.
AWS SSO:
There is a standard integration in the AWS Documentation.
https://docs.aws.amazon.com/singlesignon/latest/userguide/okta-idp.html
AWS WorkSpaces:
You mentioned that you use currently SimpleAD, in case you want to switch the IdP for your WorkSpaces you should be aware that you need to re-provision the WorkSpaces. I've not as much experience with OKTA, but I think there are two options.
In case you've already a Active Directory you should be able to integrate it with WorkSpaces (AD Connector or AWS Managed AD with forest trust)
https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust.html
https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html
In case there is no pre-existing AD, you should be able to sync the users with a AWS Managed AD.
https://help.okta.com/en/prod/Content/Topics/Directory/ad-agent-integrate-existing.htm
OKTA MFA integration for WorkSpaces:
https://aws.amazon.com/blogs/desktop-and-application-streaming/integrating-okta-mfa-with-amazon-workspaces/
I wanted to use a service account to manage VM instances on GCE remotely. It did not work. Therefore this question. One difference I found between a service account and a user account, after many hours of trial-error, is that there seems no way to use a service account to ssh in to a VM instance.
What are the other differences?
Links I found related to my question:
https://groups.google.com/forum/#!topic/gce-discussion/Z6OMpVhvowQ
Logging into google compute engine with a service account
The accepted answer is correct but lacks a deeper understanding of what credentials are in Google Cloud.
There are a number of types of credentials. User, Service Account, Group, Domain, etc. The difference is what the credentials represent and what is the authority for those credentials. Internally they are the same in regards to structure, content, etc.
All of the credential types are OAuth 2 credentials. A User Account credential is one that is issued by Google Accounts, G Suite or Identity Server. These credentials cannot be created by you or your software without Google. These credentials are issued by Google. Service Accounts, on the other hand, can create their own credentials as the service account contains the private key used to sign the credentials. The private key is used to create a Signed JWT that is then exchanged for OAuth Access Token, Refresh Token, and Identity Token. A Service Account is just a type of OAuth credential.
Google does not want User Credentials used to access Google Cloud resources except through the Google Cloud Console or Google Cloud SDK Tools and CLI. This is a security issue and design. Otherwise, the use and behavior are nearly identical except that some privileges cannot be assigned to some credential types.
By design, service accounts in Google are meant for non human users. They are a type of account used by resources in your google project (i.e. compute engine service account, app engine service account and etc).
Service accounts are designed as a type of account that is used by your Google cloud resources to communicate with other Google cloud services i.e. GCE to App Engine to Cloud Function or App Engine to google APIS like: vision API, speech to text...), or App Engine to Cloud SQL, etc.
You may refer to google documentation here for more details:
I am just starting to use GCP and I have some questions about the service accounts.
Say there is a team of like 4 remotely located developers and we all want to use the python API to access GCP to launch instances and run stuff on them. My question is should every user get their own service account and keys or should one service account be shared by all? What is the intended use case here?
Google Cloud Service Accounts provide both identity and authorization to Google Cloud.
They are similar to user accounts. If you would like to do auditing or logging of actions with service accounts, you will want to use separate service accounts per user.
Service accounts are typically used for software applications to authorize their actions with the Google Cloud APIs. Service Accounts are using to issue OAuth 2.0 Access Tokens and optionally OIDC Identity Tokens. These tokens are what provides your application with authorization in Google Cloud.
My question is should every user get their own service account and
keys or should one service account be shared by all?
Yes, you should issue separate service account JSON key files to each developer. In the same way that you would not share usernames and passwords for computer systems, you would not share service accounts.
I have written a bunch of articles on Google Cloud Service Accounts that might help you understand how to configure and use them:
Google Cloud Service Accounts
I am setting up an AWS Account, the account will be used by an organization of employees for EC2 use/experimentation. Obviously, I do not want to distribute the root login info or set up one single IAM user for everyone to use. Unfortunately, I do not have the time to manage creating individual IAM users for everyone on a regular basis.
So, is there a way to auto-create IAM users based on a given email's domain on their first login attempt? The users should have read-only roles to begin, then an Administrator could give more roles as needed to each user. I am open to suggestions, perhaps lambda functions or linking to an identity provider?
Keep in mind that these new IAM users need to have access to the AWS Management Console, this is not necessarily intended for login to applications hosted on AWS.
Update:
Moving forward using this AWS Management Console Federation Proxy Sample found in Amazon's code reference, using with Microsoft Exchange hosted email.
If your existing identity provider supports SAML2 Federation, you can set it up to login to the AWS Management Console.
For more details refer Enabling SAML 2.0 Federated Users to Access the AWS Management Console.
Else you can implement a custom Federation Broker to return an URL to the user, after they authenticate with their corporate credentials.
For more details refer Creating a URL that Enables Federated Users to Access the AWS Management Console (Custom Federation Broker).