Say I have a business and multiple DBA (doing business as), on AWS I can create a org hierarchy of the business and DBAs. I can invite the DBA accounts into the business org and link them so the business org is the payer. This keeps the operations of DBA independent and isolated with the convenience of consolidated billing for the business. This can also make it easy to transfer ownership of the DBA if desired without effecting the operations.
I was looking to setup something similar on GCP but it seems like each org is tied to a domain and there is no way to invite one org into another to link and provide billing. Is this correct or are there ways to link and provide billing for one org on behalf of the other?
Say I have a business and multiple DBA (doing business as), on AWS I
can create an org hierarchy of the business and DBAs.
You can create a similar hierarchy on Google Cloud.
I can invite the DBA accounts into the business org and link them so
the business org is the payer.
You can accomplish this with Google Cloud but in a different way. You cannot make one organization a branch/child of another organization, but you can add its members (identities) to another organization. The key to this is the members are not actually part of the organization. Identities are independent and added and removed easily.
This keeps the operations of DBA independent and isolated with the
convenience of consolidated billing for the business.
Google Cloud supports one or more billing accounts. Bill accounts can be assigned to projects independently of organizations. I can make my billing account responsible for any Google project (oversimplification).
This can also make it easy to transfer ownership of the DBA if desired
without affecting the operations.
Google does not have this flexibility without effort. In Google Cloud, I would not merge projects into an organization unless this objective was permanent. Instead, I would add the members required to access that project to IAM.
Projects independent of an organization can still participate in another organization and vice versa. Google Cloud Identity and Access Management (IAM) is very flexible. If I want bob#example.com to have access to Project ABC, I can add his email address to IAM and grant roles. You can also add an entire domain of users *#example.com to Google IAM. There are many more options.
You can move projects around inside the organization, but you cannot move projects to a different organization yourself - this requires opening a support ticket with Google Cloud Support.
I was looking to set up something similar on GCP but it seems like each
org is tied to a domain
Google Cloud is not tied to a domain name, Google G Suite is. If you plan to also use G Suite for multiple DBA, I would have separate Google accounts and not combine G Suite with my resources in Google Cloud. Note: G Suite supports multiple domains; for a single organization linking G Suite and Google Cloud is fine.
I find Google Cloud's method of organizations, folders, projects and IAM more flexible than AWS.
AWS and Google have powerful IAM systems. I know both very well, each has its positives and drawbacks.
While the answer from John tells what all might be possible, it didn't have details on how to do it. After a lot of searching online and experimenting I managed to do what I wanted. Below are the steps using the "business" and "dba" references in my question.
Create a payment profile with primary contact say
billing#businessdomain
Make sure the account type is Business and
not Individual. In my case, I some how ended up with an Individual
account. It is not allowed to change the account type once created.
Don't know why, but this was my first hurdle.
With business account type, it is possible to invite other users.
I wasn't sure
how to create a business account and if I could use the same email
for the business account type. From within GCP, I went ahead and did
the billing setup. Based on my login user which had the individual
payment profile, it defaulted the payment profile but allowed me to
create a new profile. I picked account type as Business but all
other details were same as what I had in the other personal account
that got created. Luckily, it went ahead and created a business
payment profile.
Once I had the business payment profile, I could
go ahead and invite user from my dba by specifying the email, say
billing#dbadomain
That email got an invitation and upon accepting
it, was linked to the same payment profile. This is the key! This
essentially allows payment profile associated with one domain
(organization) can be used for the billing account of another domain
(organization).
At this point, I went ahead and even closed the
payment profile with Individual account type and it seemed to have
worked. I didn't have any transactions so far and so it's like it
never need to exist. I wish it was possible to change the account
type for such profiles.
With this setup, the dba organization and its operations are done isolated and if ever it needs to change ownership, it can add a different billing method and separate out from the business org completely.
Related
I am creating an AWS organization and some member accounts within their own OUs (organizational Unit). Is there a way to create new accounts in the OUs from the member accounts or is the only way to create new accounts from within the Management account?
For example: account a-acc is in OU a-ou and has a service catalog product to create new accounts in a-ou but not only there. If this is possible, how can I do it?
As far as I'm aware, the only way to create new accounts in an AWS organization is via the Organizations API in the management account.
It appears what you want to do is provide self-service tenant provisioning capabilities to your teams. There's a few options
Use AWS Control Tower Account Factories expose them via AWS Marketplace to member accounts
Use a custom AWS Marketplace service (e.g. the "old" Account Vending Machine solution)
Build an in-house tenant provisioning process outside of AWS, e.g. with GitOps or an existing service management portal (ITSM)
With all of these solutions you need to implement a form of the "same OU" restriction you mention. For the AWS marketplace based solutions you can e.g. create a product wrapping the "generic" account factory and pre-populate the OU parameter for where the account is going to be placed. This means that you have to create and manage many different "wrapping" products.
From my experience with setting up resource hierarchies for enterprises on many different clouds its much better to stay flat and refrain from modeling your organizational structure (e.g. departments, teams, divisions) into the cloud resource hierarchy. Most IT systems outlive the organizational structure they were born from and re-organizing your cloud resource hierarchy is usually pretty painful. I'm just mentioning this here because your "same OU" restriction sounds like "I want to give this team their own OU and manage their own accounts".
If this accurately describes what you're trying to accomplish, here's some ideas for alternatives
model organizational hierarchy like department etc. as tags on accounts instead of mapping to OUs
leverage a cloud foundation platform that can enforce permission models (who can create a new account) and tagging (e.g. accounts requested by this team always get tagged with their team id)
first of all
dont use aws organisations but use AWS Control Tower
secondly
either way cotrol tower or organisation
you can use aws service catalog to create new accounts
Yes, you can create AWS accounts from member accounts. To do this, you'll need to provide your Amazon account credentials and select the AWS account type ( Individual , Business , or Partnership ) that corresponds to your organizational structure. You'll then be prompted to enter your organization's primary contact information ( Corporate Email Address and Phone Number ). After you've completed these steps, you'll be able to create an AWS account and begin using AWS services.
Is it possible to change the Organisation Ownership of a Google Cloud Account from one organisation to another?
Initially we setup the account under domain.net.au.
Our company was purchased by another company and has setup emails using google under domain.ag.
My boss is now wanting the Google Cloud Account and all its projects to be moved over to domain.ag.
Is this possible without having to re-create them all in the new location?
We have a massive database that is highly important to our company that needs to have almost no downtime.
thanks!
Changing organisational ownership I think you really have to contact support. But if what you meant is moving your resources from the old organisation account to the new one,Yes it is possible to Move resources from one organisation to another. With the right Migration plans and the projectmover roles to the required accounts you can. But note that the resources would not inherit policies from previous organisations hence you have to do accurate setup for your new organisation. Just do an inventory record of what's in the current organisation to know how to prepare the new organisation to avoid issues. If you encounter any error, then you can rollback
To change the organization ownership first you need to contact google support. Also yes, it is possible if you want to move your resources from an old organization account to a new organization account with correct migration plans and roles. Kindly make a note here, the resources would not inherit policies from previous organisations. Hence you need to do the exact setup for your new organization account.
Steps to change Organizational ownership.
Create a list of projects that you’d like to move.
Move all the projects out of any folders in the current organization and into the top level.
Contact Support with a list of projects that you’d like to move from the current organization to another organization.
Support will move the projects out of the current organization so they have no parent (no organization).
Move all the projects into the new organization.
I have used Google Cloud for a while for my own projects. But this time I would like to deploy one of my customer's project to it. What is the best way to manage the fees?
Creating the project in my GC account and granting access to the customer to see the fees and send them invoices.
Creating the project in my GC account and somehow set their billing account to my project.
Creating the project in their GC account and ask for permissions to manage it.
Something else.
Which one is the correct solution, or what do you use? If the second solution is the good one, how can I achieve it?
Thank you!
Let's review each option and consider everything from both you as the developer and the client who owns (pays for) the project. Think security and responsibility (legal, financial and ethical) when making these decisions.
Option 1:
Creating the project in my GC account and granting access to the
customer to see the fees and send them invoices.
I would create a separate project for this customer and not mix their work into a project that has your own work. Granting the customer access to the billing information for a mixed account and then trying to separate items might take more time than it is worth. I don't recommend this method.
Option 2:
Creating the project in my GC account and somehow set their billing
account to my project.
The customer will need to grant you access to their billing account which I do not recommend. I would not grant access to my billing account to a third party. They could attach any project they want I would get the bill. I don't recommend this method.
Option 3:
Creating the project in their GC account and ask for permissions to
manage it.
This is the best option. The project and billing are under the client's control and the client grants you the required permission such as Project Editor to your user identity. Project Ownership and Billing responsibility remains with the client and the client can grant and remove access to you anytime they want easily without a ripple effect of additional work.
This all depends on your preference, however, I would go with the second one. You can create the project for them, and they can create the billing account. You then can modify the billing account on the project you created by following the steps over here.
Nevertheless, as I mentioned this is all your preference so you can use any of the other approaches you mentioned too.
Hope you find this useful.
Disclaimer: https://console.cloud.google.com/support/community leads here. Google's documentation is horrific so giving this a whirl on the off chance that I don't get downvoted to the depths of dev/null
Out of impending necessity I am migrating a private application that monitors our Gmail accts to OAuth 2, and as part of this process it was necessary to create an OAuth consent screen. Since this application will only be used internally it makes the most sense to choose "Internal" for Application Type - which is described as follows:
Only users with a Google Account in your organization can grant access to the scopes requested by this app.
The users on this Project consist of two "owners" — myself using my personal Gmail acct, and
another employee who is part of the company G Suite account.
My question is who qualifies as a "user in my organization"? Is this based on the project owners? Does my non-G-Suite account (which is an owner of the project) qualify? Does the inclusion of one member in a G Suite account automatically associated the other employee accounts? Is the anywhere to actually see these users or manage them directly?
I'd actually like to add another couple accounts to the mix but still keep the application private, but I'm confused about how Google determines which gmail accounts will be able to authorize the app.
UPDATE: To clarify, when I visit the consent page while logged in as a member of our G Suite on the same domain as the project owner, everything is fine. However, we have other members managed in the same G Suite account who are under a different domain and for these I get the message:
Error 403: org_internal
This client is restricted to users within its organization.
Furthermore, I am not even able to grant access using my own email which is the creator and owner of the application. I'd like to know how I can add myself and the other G Suite members to be able to grant access to the application without making it public. It was suggested below that I add them (or their domain) to Google Cloud IAM but I'm unclear about how to get this working. My own email does already exist in IAM with role of "owner" and apparently that doesn't satisfy the requirement.
In order for internal apps to be used for OAuth, the project must belong to the organization associated with the same GSuite customer as all the users.
non-GSuite accounts cannot be used by internal apps. There's more information about this here: https://support.google.com/cloud/answer/6158849#public-and-internal.
Who is a member of my organization?
Anyone that you have added to Google Cloud IAM for a project, folder or at the organization level. This can include Google Accounts (Gmail email addresses), G Suite and Google Identity. The last two use a domain name (example.com) and anyone with an identity in that domain (someone#example.com).
Google's goal is to tighten up security for Google Cloud Platform. In the past anyone with a Google Accounts email address could use your projects OAuth to request access. The level of access is controlled by OAuth Scopes. Today, granting that access results in a Consent Screen with an unverified application warning. To get beyond (remove) that warning often requires a security audit of your application with a cost estimated at $75,000 USD.
How do I manage members?
Through Google Cloud IAM. You can add and remove members; assign and remove IAM roles attached to member IDs. Through G Suite or Google Identity by adding or removing member accounts. Don't forget that members can be part of a Google Group and part of a Domain each of which are also an identity in Google Cloud Platform.
For GSuite Users:
Cloud IAM only deals with authorisation you would need to handle authentication elsewhere. By default GSuite integrates with CloudIAM as a default authentication provider.
For Non-GSuite Users:
You can use cloud identity free edition but users will have to manage separate set of credentials.
Single Sign On without GSuite
If you want Single Sign On Option you can also use Google Cloud Directory Sync to sync with your on-premise Active Directory or LDAP server for authentication. So users can keep their login details.
That's how authentication works on GCP. As for authorisation you have CloudIAM where you can manage access through Predefined Roles, Primitive Roles and Custom Roles.
Cloud IAM and Authorisation
Typically you assign access using google groups and resource hierarchy to make it easier for you to manage user access. But bear in mind that if you grant an access to something through a ascenstor folder in resource hierarchy then you can't deny access downstream. So you need to plan access hierarchy accordingly.
To answer your question who qualifies as a "user in my organization"?, everyone can login but by default they cannot access any projects, it's resources or apis unless they are given access to either individually or through a group.
Hope this clarifies things for you a little.
In our team, we are using AWS as our main cloud provider and currently, we have 3 projects hosted on their platform.
We are about to have 2 more projects in the next weeks, but first, we want to organize our projects, because our current organization is a little bit disordered.
We want our projects to be organized following these rules:
Each project must have a staging and production environment.
Each project is independent of each other so that it is not possible to see the resources of a project from within another project, i.e., VPC and S3 Buckets.
The client is responsible for paying the bills of the project (staging and production environment).
Even though the client is responsible for paying the bills, we must have access to the environments to deploy our code and to do other tasks related to development, testing, and operations.
We can assign a team of developers to each project. It should be possible for a developer to be in one or more projects at the same time. Plus, it should be possible to move our developers between projects and to remove their access from a project.
So, is it possible to organize projects in AWS under the rules previously mentioned?
If so, what are good resources to learn how to do this?
If not, what cloud providers allow to organize projects the way we want?
Thanks for your attention and time. I'm looking forward to your replies.
The fact that you want project-specific charges to go to customers and you want each project to be independent indicates that your best choice would be to use a separate AWS Account for each project (or each client).
By keeping projects in separate AWS accounts:
Each account will only have costs associated with a particular project
Resources in each account will be kept separate
User permissions in each account will be kept separate
You can create staging and production environments within the same account (see below)
You can have multiple accounts joined together by using AWS Organizations:
AWS Organizations is an account management service that enables you to consolidate multiple AWS accounts into an organization that you create and centrally manage. AWS Organizations includes account management and consolidated billing capabilities that enable you to better meet the budgetary, security, and compliance needs of your business. As an administrator of an organization, you can create accounts in your organization and invite existing accounts to join the organization.
Some companies go one step further and also keep staging and production in separate AWS accounts. They do this because they wish to keep production resources and users away from non-production resources and users. This reduces the chance of somebody accidentally changing Production when they meant to update Staging. While you can use IAM permissions to reduce such a thing from happening, keeping staging and production in separate accounts guarantees that people with only staging permissions will not be able to impact production.
Your company should maintain ownership of all of the accounts so that you can manage and control them. Each month, you will receive a consolidated bill, but it will show costs broken down by account. Thus, you will know how much to charge your clients.
The developers will need separate logins to each AWS account. So, if they wish to work on Project 1, they will need to login to the AWS account for Project 1. They then have access to the resources in Project 1, but not any of the other projects. When they wish to work on another project, they will need to re-login with credentials for the other project's AWS account. You might think that this adds extra work, but it also adds extra security and ensures that each client's resources are kept totally separate.
A final benefit of using separate accounts is that, in future, if a client wishes to take control of their systems, you can assign the AWS account to them without having to do any work to separate their resources from other clients. It is like handing over the keys of a house — they can move in without anyone having to move out.