# What is Takomo Organizations? With Takomo's organization management features, you manage organizational units, member accounts, and policies of your AWS organization. You can also easily configure and deploy CloudFormation stacks to all of your accounts or choose to deploy to accounts that belong to a specified organizational unit. {% hint style="info" %} This documentation does not explain how AWS organizations work or how it should be used. It's highly recommended that you read through [the official AWS documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) before diving deeper. {% endhint %} # Introduction You specify how you want your organization to look like in the organization configuration file, i.e., what kind of organizational units hierarchy you want, in which organizational units your accounts should belong to and what organization policies you want to apply to your accounts. {% hint style="info" %} The examples under this section always build on top of the previous examples. So, whenever a new topic or feature is introduced, the examples demonstrating its usage will continue from the previous example. {% endhint %} # Directory structure Configuration related to organization management goes under the **organization** directory in your Takomo project directory. Inside it, there is the **organization.yml** file that contains most of the organization configuration and four directories - one for each type of organization policy. ```bash . ├─ stacks ├─ templates ├─ helpers ├─ partials ├─ resolvers ├─ hooks ├─ schemas ├─ deployment ├─ config-sets └─ organization ├─ service-control-policies ├─ tag-policies ├─ backup-policies ├─ ai-services-opt-out-policies └─ organization.yml ``` The rest of the directories are explained [here](https://docs.takomo.io/configuration/directory-structure). # Master account You need to specify the organization master account in the organization configuration. Takomo uses this information to ensure that organization management operations target the correct AWS organization. Use `masterAccountId` property to specify the master account. #### Example This is how you specify the master account id. {% code title="organization/organization.yml" %} ```yaml masterAccountId: "098765432100" ``` {% endcode %} # Organizational units You define the hierarchy for your organizational units (OUs) with the `organziationalUnits` property at the top level of the organization.yml file. It's an object whose keys are OU paths, and values are configuration for the corresponding OUs. The root OU of the hierarchy is always **Root**, and all other OUs are its children. #### Examples This is the minimum hierarchy. As you can see, you must have the Root OU but you don't have to provide configuration for it. {% code title="organization/organization.yml" %} ```yaml masterAccountId: "098765432100" organizationalUnits: Root: {} ``` {% endcode %} Here we have a more complex hierarchy with some nested OUs. {% code title="organization/organization.yml" %} ```yaml masterAccountId: "098765432100" organizationalUnits: Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: {} Root/Sandbox: {} ``` {% endcode %} The above configuration is flat but represents this kind of hierarchy: ```bash Root ├─ Workloads │ ├─ Dev │ ├─ Test │ └─ Prod └─ Sandbox ``` # Accounts Every account of your AWS organization belongs to some OU. To place an account to an OU, you add the account to the `accounts` property of the OU in question. The `accounts` property is a list that accepts plain account ids and account objects that let you provide additional account-specific configuration. {% hint style="info" %} AWS account id may begin with zero and that is why account ids must always be strings in Takomo configuration, i.e., the id must be quoted like so "012345678901". {% endhint %} #### Example Here's an example of how to put accounts into OUs. The account 876754648373 is defined with object notation. The other accounts are defined as plain account ids. {% code title="organization/organization.yml" %} ```yaml masterAccountId: "098765432100" organizationalUnits: Root: accounts: # This is the organization master account - "098765432100" Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: # Account using the object notation - id: "876754648373" Root/Sandbox: # Only the id is given for these accounts accounts: - "123456789012" - "448873940474" ``` {% endcode %} ## Additional configuration The account id is the only required information for accounts. With object notation, you can provide additional information. ### Name You can specify the account name with the `name` property. The name helps you to identify the account. Takomo uses the name to verify that the account configuration is valid, i.e., there actually exists an account with the given id and name. {% hint style="info" %} Please note that Takomo won't update the actual account name to match what you have defined in the configuration. {% endhint %} #### Example Here's how to specify the name for account 876754648373.. {% code title="organization/organization.yml" %} ```yaml masterAccountId: "098765432100" organizationalUnits: Root: accounts: - "098765432100" Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" # Account name is specified like this name: MyAccount Root/Sandbox: accounts: - "123456789012" - "448873940474" ``` {% endcode %} ### Email You can specify the account email with the `email` property. The email helps you to identify the account. Takomo uses the email to verify that the account configuration is valid, i.e., there actually exists an account with the given id and email. {% hint style="info" %} Please note that Takomo won't update the actual account email to match what you have defined in the configuration. {% endhint %} #### Example Here's how to specify the email for account 876754648373. {% code title="organization/organization.yml" %} ```yaml masterAccountId: "098765432100" organizationalUnits: Root: accounts: - "098765432100" Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount # Account email is specified like this email: account@example.com Root/Sandbox: accounts: - "123456789012" - "448873940474" ``` {% endcode %} ### Description You can give a short description for an account with the `description` property. #### Example Here's how to specify the description for account 876754648373. {% code title="organization/organization.yml" %} ```yaml masterAccountId: "098765432100" organizationalUnits: Root: accounts: - "098765432100" Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount email: account@example.com # Account description is specified like this description: This is a production account Root/Sandbox: accounts: - "123456789012" - "448873940474" ``` {% endcode %} # Policies You can have four types of policies in your AWS organization: service control policies, tag policies, backup policies, and AI services opt-out policies. You can use Takomo to manage all of these. ## Policy files You use policy files to store the policies you want to deploy to your AWS organization. Each policy type has its own directory from where Takomo looks for the policies. | Policy type | Directory | | ---------------------------- | ---------------------------- | | Service control policies | service-control-policies | | Tag policies | tag-policies | | Backup policies | backup-policies | | AI services opt-out policies | ai-services-opt-out-policies | #### Example Here's an example of a service control policy that denies everything from regions that are not explicitly allowed. Because it's a service control policy, it needs to be placed into the **service-control-policies** directory. {% code title="organization/service-control-policies/restrict-by-regions.json" %} ```yaml { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyAllOutsideAllowedRegions", "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": [ "us-east-1", "eu-central-1", "eu-west-1", "eu-west-2", "eu-west-3", "eu-north-1" ] } } } ] } ``` {% endcode %} ## Declaring policies Once you have policy files in the correct directories, you can declare them in the organization configuration. Each policy type has its own property under which you declare the policies. | Policy type | Property | | ---------------------------- | ------------------------ | | Service control policies | serviceControlPolicies | | Tag policies | tagPolicies | | Backup policies | backupPolicies | | AI services opt-out policies | aiServicesOptOutPolicies | Each of the above are objects whose keys are policy names and values are configuration for the corresponding policy. The policy name is the file name of the policy file, excluding the file extension. #### Example Here's how you would declare the service control policy we created in the previous example: {% code title="organization/organization.yml" %} ```yaml masterAccountId: "098765432100" # Use serviceControlPolicies property # to specify service control policies serviceControlPolicies: restrict-by-regions: description: Restrict regions organizationalUnits: Root: accounts: - "098765432100" Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount email: account@example.com description: This is a production account Root/Sandbox: accounts: - "123456789012" - "448873940474" ``` {% endcode %} ## AWS managed policies There is a default service control policy named **FullAWSAccess** which is managed by AWS. You can't provide your own policy with this name. You can still use this policy with your organizational units and accounts by declaring it with `awsManaged: true`. Because AWS manages the policy, you don't need to provide a policy file for it. #### Example Here's how you declare the AWS managed policy: {% code title="organization/organization.yml" %} ```yaml masterAccountId: "098765432100" serviceControlPolicies: restrict-by-regions: description: Restrict regions # This is the AWS managed default service control policy FullAWSAccess: description: AWS managed default policy awsManaged: true organizationalUnits: Root: accounts: - "098765432100" Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount email: account@example.com description: This is a production account Root/Sandbox: accounts: - "123456789012" - "448873940474" ``` {% endcode %} ## Attaching policies You can attach declared policies to OUs and accounts with the following properties. | Policy type | Property | | ---------------------------- | ------------------------ | | Service control policies | serviceControlPolicies | | Tag policies | tagPolicies | | Backup policies | backupPolicies | | AI services opt-out policies | aiServicesOptOutPolicies | Each of them accepts a single policy name or a list of policy names. Service control policies behave differently than others policies. If you attach a service control policy to an OU, it is also attached automatically to all OUs and accounts under that OU. If you attach any other policy to an OU, the policy is not attached to OUs and accounts under the first OU, but they inherit the policy instead. #### Example Let's add one backup policy named **MyBackups** and attach it directly to account 123456789012. Then, we attach the AWS managed default service control policy **FullAWSAccess** to Root OU, so it will be inherited by all OUs and accounts in the organization. Finally, we want our workload accounts under **Root/Workloads** OU to be restricted to use only the allowed regions, so we attach the restrict-by-regions policy to it. {% code title="organization/organization.yml" %} ```yaml masterAccountId: "098765432100" serviceControlPolicies: restrict-by-regions: description: Restrict regions FullAWSAccess: description: AWS managed default policy awsManaged: true backupPolicies: MyBackups: description: Backup policy organizationalUnits: Root: serviceControlPolicies: FullAWSAccess accounts: - "098765432100" Root/Workloads: serviceControlPolicies: restrict-by-regions Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount email: account@example.com description: This is a production account Root/Sandbox: accounts: - id: "123456789012" backupPolicies: - MyBackups - "448873940474" ``` {% endcode %} # Deploying organization You use the deploy organization command to make your AWS organization match the configuration found in the organization configuration file. #### Example This is how you deploy your configuration: ```bash tkm org deploy ``` ## Organization admin role By default, Takomo uses the credentials currently available in the terminal session to execute operations that query information from the organization and alter its state. You can also instruct Takomo to use a specific IAM role to perform these organization management operations by setting the `organizationAdminRoleName` property in the organization configuration. {% hint style="info" %} Please note that you need to give only a role name and not a full role ARN. {% endhint %} #### Example This is how you set the organization admin role. {% code title="organization/organization.yml" %} ```yaml masterAccountId: "098765432100" # This is how you tell Takomo to use an IAM role # named 'MyOrganizationAdminRole' when executing # organization management actions. organizationAdminRoleName: MyOrganizationAdminRole serviceControlPolicies: restrict-by-regions: description: Restrict regions FullAWSAccess: description: AWS managed default policy awsManaged: true backupPolicies: MyBackups: description: Backup policy organizationalUnits: Root: serviceControlPolicies: FullAWSAccess accounts: - "098765432100" Root/Workloads: serviceControlPolicies: restrict-by-regions Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount email: account@example.com description: This is a production account Root/Sandbox: accounts: - id: "123456789012" backupPolicies: - MyBackups - "448873940474" ``` {% endcode %} # Creating accounts You create new accounts to your organization using the [create account command](/command-line-usage/account/create-account). #### Example Create a new account: ```bash tkm org accounts create \ --email my-account-1@example.com \ --name my-account ``` ## Account defaults When creating a new account, you can optionally specify if the account's IAM users should have access to the account's billing information and what is the name of the IAM role AWS Organizations creates in the account. You can use `accountCreation` property specify the default values for these options in the organization configuration file: {% code title="organization.yml" %} ```yaml # This is how you set the defaults for account creation. accountCreation: defaults: iamUserAccessToBilling: true roleName: MyAccountAdminRole masterAccountId: "098765432100" organizationAdminRoleName: MyOrganizationAdminRole serviceControlPolicies: restrict-by-regions: description: Restrict regions FullAWSAccess: description: AWS managed default policy awsManaged: true backupPolicies: MyBackups: description: Backup policy organizationalUnits: Root: serviceControlPolicies: FullAWSAccess accounts: - "098765432100" Root/Workloads: serviceControlPolicies: restrict-by-regions Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount email: account@example.com description: This is a production account Root/Sandbox: accounts: - id: "123456789012" backupPolicies: - MyBackups - "448873940474" ``` {% endcode %} ## Account contraints You can set accepted pattern for account name and email by providing `constraints` property under account creation configuration: {% code title="organization.yml" %} ```yaml accountCreation: defaults: iamUserAccessToBilling: true roleName: MyAccountAdminRole # This is how you set constraints for account name and email. constraints: # Account name must match this regex pattern namePattern: "^my-account-[a-z0-9-]+$" # Account email must match this regex pattern emailPattern: "^admin\\+my-account-[0-9a-z-]+@example.com$" masterAccountId: "098765432100" organizationAdminRoleName: MyOrganizationAdminRole serviceControlPolicies: restrict-by-regions: description: Restrict regions FullAWSAccess: description: AWS managed default policy awsManaged: true backupPolicies: MyBackups: description: Backup policy organizationalUnits: Root: serviceControlPolicies: FullAWSAccess accounts: - "098765432100" Root/Workloads: serviceControlPolicies: restrict-by-regions Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount email: account@example.com description: This is a production account Root/Sandbox: accounts: - id: "123456789012" backupPolicies: - MyBackups - "448873940474" ``` {% endcode %} # Account aliases You set and remove account aliases for you accounts using [create account alias](/command-line-usage/account/create-account-alias) and [delete account alias](/command-line-usage/account/delete-account-alias) commands, respectively. Here's how you create account alias: ```bash tkm org accounts create-alias \ --account-id 123456789012 \ --alias my-alias ``` And here's how to remove it: ```bash tkm org accounts delete-alias --account-id 123456789012 ``` # Listing accounts You can list accounts in your organization with [list accounts](/command-line-usage/account/list-accounts) command. ```bash tkm org accounts list ``` # Config sets You use config sets to specify which CloudFormation stacks you want to deploy to your organization's member accounts. ## Config set directory and files Config sets are standard Takomo stack configurations‚ but instead of the stacks directory, you put them to subdirectories under the **config-sets** directory. The directory names become the names of the config sets, and you use them to refer to the config sets in the organization configuration file. You place your stack group and stack configuration files directly in the config set directory's root. Other Takomo directories such as the templates directory remains in the project's root. #### Example Here is an example with two config sets named **common** and **network**. ``` . ├─ templates ├─ config-sets │ ├─ common # config set named 'common' │ │ ├─ budgets.yml │ │ └─ cloudtrail.yml │ └─ network # config set named 'network' │ ├─ config.yml │ └─ vpc.yml └─ organization └─ organization.yml ``` The common config set has two stacks: budgets.yml and cloudtrail.yml. The network config set has vpc.yml stack and a stack group configuration file config.yml. ## Attaching config sets You can attach config sets to organizational units or accounts. Organizational units and accounts inherit config sets from the organizational unit they belong to. They can add config sets of their own but can't remove the config sets they inherited. You attach config sets to organizational units and accounts by providing single config set name or a list of config set names in their `configSets` property. #### Example Let's continue the organization configuration we started in the previous chapters and see how to attach our config sets to accounts. {% code title="organization.yml" %} ```yaml accountCreation: defaults: iamUserAccessToBilling: true roleName: MyAccountAdminRole constraints: namePattern: "^my-account-[a-z0-9-]+$" emailPattern: "^admin\\+my-account-[0-9a-z-]+@example.com$" masterAccountId: "098765432100" organizationAdminRoleName: MyOrganizationAdminRole serviceControlPolicies: restrict-by-regions: description: Restrict regions FullAWSAccess: description: AWS managed default policy awsManaged: true backupPolicies: MyBackups: description: Backup policy organizationalUnits: Root: serviceControlPolicies: FullAWSAccess accounts: - "098765432100" # Attach 'common' config set to this OU which # makes all OUs and accounts under this OU to # inherit it. configSets: common Root/Workloads: serviceControlPolicies: restrict-by-regions Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount email: account@example.com description: This is a production account # Attach 'networking' config set diretly # to this account. configSets: - networking Root/Sandbox: accounts: - id: "123456789012" backupPolicies: - MyBackups - "448873940474" ``` {% endcode %} We attached the **common** config set to the Root organizational unit which attaches it to all OUs and accounts that are located under the Root OU. We chose a different approach with the networking config set and attached it directly to account 876754648373. ## Account admin role When you deploy config sets to your accounts, Takomo assumes an IAM role from each account and uses it to execute the deployment. By default, Takomo attempts to assume a role named **OrganizationAccountAccessRole**, but you can change the role by providing a different role name in `accountAdminRoleName` property. This property can be used at the top-level of organization configuration, in organizational units, and in accounts. {% hint style="warning" %} The credentials used to run the deploy command must have permissions to assume the account admin role from each account. {% endhint %} #### Example This is how you specify the account admin role. {% code title="organization.yml" %} ```yaml accountCreation: defaults: iamUserAccessToBilling: true roleName: MyAccountAdminRole constraints: namePattern: "^my-account-[a-z0-9-]+$" emailPattern: "^admin\\+my-account-[0-9a-z-]+@example.com$" masterAccountId: "098765432100" organizationAdminRoleName: MyOrganizationAdminRole # Define the account admin role at the top-level accountAdminRoleName: MyAccountAdminRole serviceControlPolicies: restrict-by-regions: description: Restrict regions FullAWSAccess: description: AWS managed default policy awsManaged: true backupPolicies: MyBackups: description: Backup policy organizationalUnits: Root: serviceControlPolicies: FullAWSAccess accounts: - "098765432100" configSets: common Root/Workloads: serviceControlPolicies: restrict-by-regions # Set the account admin role for this # organizational unit. Overrides the value # given at the top-level. All OUs and accounts # under this OU will inherit the account # admin role name. accountAdminRoleName: AnotherAdminRole Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount email: account@example.com description: This is a production account configSets: - networking Root/Sandbox: accounts: - id: "123456789012" # Define the account admin role only # for this account. accountAdminRoleName: AccountSpecificRole backupPolicies: - MyBackups - "448873940474" ``` {% endcode %} # Bootstrap config sets Typically, you use a CI/CD pipeline to deploy stacks to your organization accounts. That usually means creating an IAM role for the CI/CD tool to assume and then use to perform the deployment. Of course, as a best practice, the deployment role should have only the minimum set of permissions. The next question is how you create that deployment role in the first place. Takomo's approach to this problem is to divide config sets into two categories: **standard** and **bootstrap**. The standard config sets are the ones you would deploy using the deployment role with a minimum set of permissions. The bootstrap config sets are, like the name implies, for bootstrapping resources needed to deploy the standard config sets, e.g., creating the deployment role. Deploying the bootstrap config sets should be a lightweight operation that you can run from your personal laptop with full admin permissions secured with MFA, or using some other automated but more restricted and secure option. In the [previous page](/account-stacks/config-sets) we learned about standard config sets. This page explains how to use bootstrap config sets. ## Differences to standard config sets The only difference between the standard and bootstrap config sets is how you attach them to organizational units and accounts, and how you specify the IAM role Takomo assumes during the deployment. ## Attaching bootstrap config sets You attach bootstrap config sets to organizational units and accounts the same way you would attach standard config sets. Only the property name is different. For bootstrap config sets, you use the `bootstrapConfigSets` property. #### Example Let's define a bootstrap config set named **deployment-role** and attach it to the Root organizational unit: {% code title="organization.yml" %} ```yaml accountCreation: defaults: iamUserAccessToBilling: true roleName: MyAccountAdminRole constraints: namePattern: "^my-account-[a-z0-9-]+$" emailPattern: "^admin\\+my-account-[0-9a-z-]+@example.com$" masterAccountId: "098765432100" organizationAdminRoleName: MyOrganizationAdminRole accountAdminRoleName: MyAccountAdminRole serviceControlPolicies: restrict-by-regions: description: Restrict regions FullAWSAccess: description: AWS managed default policy awsManaged: true backupPolicies: MyBackups: description: Backup policy organizationalUnits: Root: serviceControlPolicies: FullAWSAccess accounts: - "098765432100" configSets: common # Attach the deployment-role bootstrap config set # to this organizational unit. bootstrapConfigSets: deployment-role Root/Workloads: serviceControlPolicies: restrict-by-regions accountAdminRoleName: AnotherAdminRole Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount email: account@example.com description: This is a production account configSets: - networking Root/Sandbox: accounts: - id: "123456789012" accountAdminRoleName: AccountSpecificRole backupPolicies: - MyBackups - "448873940474" ``` {% endcode %} ## Account bootstrap role When you deploy bootstrap config sets to your accounts, Takomo assumes an IAM role from each account and uses it to execute the deployment. By default, Takomo attempts to assume a role named **OrganizationAccountAccessRole**, but you can change the role by providing a different role name in `accountBootstrapRoleName` property. This property can be used at the top-level of organization configuration, in organizational units, and in accounts. {% hint style="warning" %} The credentials used to run the bootstrap command must have permissions to assume the account bootstrap role from each account. {% endhint %} #### Example This is how you specify the account bootstrap role. {% code title="organization.yml" %} ```yaml accountCreation: defaults: iamUserAccessToBilling: true roleName: MyAccountAdminRole constraints: namePattern: "^my-account-[a-z0-9-]+$" emailPattern: "^admin\\+my-account-[0-9a-z-]+@example.com$" masterAccountId: "098765432100" organizationAdminRoleName: MyOrganizationAdminRole accountAdminRoleName: MyAccountAdminRole # Set account bootstrap role at the top-level accountBootstrapRoleName: MyBootstrapRole serviceControlPolicies: restrict-by-regions: description: Restrict regions FullAWSAccess: description: AWS managed default policy awsManaged: true backupPolicies: MyBackups: description: Backup policy organizationalUnits: Root: serviceControlPolicies: FullAWSAccess accounts: - "098765432100" configSets: common bootstrapConfigSets: deployment-role Root/Workloads: serviceControlPolicies: restrict-by-regions accountAdminRoleName: AnotherAdminRole # Set account bootstrap role to OU accountBootstrapRoleName: AnotherBootstrapRole Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount email: account@example.com description: This is a production account configSets: - networking Root/Sandbox: accounts: - id: "123456789012" accountAdminRoleName: AccountSpecificRole # Set account bootstrap role to account accountBootstrapRoleName: AccountBootstrapRole backupPolicies: - MyBackups - "448873940474" ``` {% endcode %} # Variables You can specify variables for organizational units and accounts with the `vars` property. It is an object whose keys are variable names and values contain the values for the corresponding variables. Variable values can be strings, numbers, booleans, objects or lists of the aforementioned types. Organizational units inherit variables from their parents, and accounts inherit variables from the organizational unit they belong to. If you want to apply variables to all organizational units groups and accounts, you can define the `vars` property at the top-level of the organization configuration. #### Example This is how you use variables. {% code title="organization.yml" %} ```yaml # Top-level variables vars: cost-center: 12345 budget: 2000 accountCreation: defaults: iamUserAccessToBilling: true roleName: MyAccountAdminRole constraints: namePattern: "^my-account-[a-z0-9-]+$" emailPattern: "^admin\\+my-account-[0-9a-z-]+@example.com$" masterAccountId: "098765432100" organizationAdminRoleName: MyOrganizationAdminRole accountAdminRoleName: MyAccountAdminRole accountBootstrapRoleName: MyBootstrapRole serviceControlPolicies: restrict-by-regions: description: Restrict regions FullAWSAccess: description: AWS managed default policy awsManaged: true backupPolicies: MyBackups: description: Backup policy organizationalUnits: Root: serviceControlPolicies: FullAWSAccess accounts: - "098765432100" configSets: common bootstrapConfigSets: deployment-role Root/Workloads: serviceControlPolicies: restrict-by-regions accountAdminRoleName: AnotherAdminRole accountBootstrapRoleName: AnotherBootstrapRole # Variables for organizational unit. # Inherit all variables from the top-level, # add a new variable named 'projectCode', # and override the 'budget' variable. vars: projectCode: 1234 budget: 3000 Root/Workloads/Dev: {} Root/Workloads/Test: {} Root/Workloads/Prod: accounts: - id: "876754648373" name: MyAccount email: account@example.com description: This is a production account configSets: - networking Root/Sandbox: accounts: - id: "123456789012" accountAdminRoleName: AccountSpecificRole accountBootstrapRoleName: AccountBootstrapRole backupPolicies: - MyBackups # Add account-specific variables vars: environmentName: sandbox foo: bar someList: - one - two - three - "448873940474" ``` {% endcode %} # Deploying config sets ## Standard config sets You use [deploy accounts](/command-line-usage/account-stacks/deploy-accounts) command to deploy standard config sets. ```bash tkm org accounts deploy ``` ## Bootstrap config sets You use [bootstrap accounts](/command-line-usage/account-stacks/bootstrap-accounts) sets command to deploy bootstrap config sets. ```bash tkm org accounts bootstrap ``` # Removing config sets ## Standard config sets You use [undeploy accounts](/command-line-usage/account-stacks/undeploy-accounts) command to remove standard config sets. ```bash tkm org accounts undeploy ``` ## Bootstrap config sets You use [tear down accounts](/command-line-usage/account-stacks/tear-down-accounts) sets command to remove bootstrap config sets. ```bash tkm org accounts tear-down ``` # Organization These are the organization commands: * [Create organization](/command-line-usage/organization/create-organization) * [Describe organization](/command-line-usage/organization/describe-organization) * [Deploy organization](/command-line-usage/organization/deploy-organization) # Create organization Create a new AWS organization and initialize a minimum organization configuration file in **organization/organization.yml**. ## Usage ```bash tkm org create [--feature-set ] ``` ## Positional arguments This command has no positional arguments. ## Options In addition to the [common options](https://docs.takomo.io/command-line-usage/common-options), this command has the following options. * `--feature-set ` * Optional. * Specifies the feature set supported by the new organization. * Allowed values are: * ALL = Enable all features (default). * CONSOLIDATED\_BILLING = All member accounts have their bills consolidated to and paid by the master account. ## IAM permissions These are the minimum IAM permissions required to run this command. ```yaml Statement: - Effect: Allow Action: - iam:CreateServiceLinkedRole - organizations:CreateOrganization Resource: "*" ``` ## Examples Create a new organization with default feature set, which is **ALL**. ```bash tkm org create ``` Create a new organization with **ALL** feature set. ```bash tkm org create --feature-set ALL ``` Create a new organization with **CONSOLIDATED\_BILLING** feature set. ```bash tkm org create --feature-set CONSOLIDATED_BILLING ``` # Describe organization Describe organization. ## Usage ```bash tkm org describe ``` ## Positional arguments This command has no positional arguments. ## Options In addition to the [common options](https://docs.takomo.io/command-line-usage/common-options), this command has no command-specific options. ## IAM permissions These are the minimum IAM permissions required to run this command. ```yaml Statement: - Effect: Allow Action: - organizations:ListRoots - organizations:DescribeOrganization - organizations:DescribeAccount - organizations:ListAWSServiceAccessForOrganization Resource: "*" ``` ## Examples Describe organization. ```bash tkm org describe ``` # Deploy organization Deploy organization configuration. ## Usage ```bash tkm org deploy ``` ## Positional arguments This command has no positional arguments. ## Options In addition to the [common options](https://docs.takomo.io/command-line-usage/common-options), this command has no command-specific options. ## IAM permissions These are the minimum IAM permissions required to run this command. ```yaml Statement: - Effect: Allow Action: - organizations:ListRoots - organizations:ListTargetsForPolicy - organizations:DisableAWSServiceAccess - organizations:DeletePolicy - organizations:DeleteOrganizationalUnit - organizations:DisablePolicyType - organizations:ListAWSServiceAccessForOrganization - organizations:DescribePolicy - organizations:ListPolicies - organizations:ListAccountsForParent - organizations:ListAccounts - organizations:EnableAWSServiceAccess - organizations:UpdateOrganizationalUnit - organizations:DescribeOrganization - organizations:UpdatePolicy - organizations:EnablePolicyType - organizations:AttachPolicy - organizations:ListOrganizationalUnitsForParent - organizations:CreateOrganizationalUnit - organizations:MoveAccount - organizations:CreatePolicy Resource: "*" ``` ## Examples Deploy organization. ```bash tkm org deploy ``` # Account Here are the account commands: * [Create account](/command-line-usage/account/create-account) * [Create account alias](/command-line-usage/account/create-account-alias) * [Delete account alias](/command-line-usage/account/delete-account-alias) * [List accounts](/command-line-usage/account/list-accounts) # Create account Create a new account into the organization. ## Usage ```bash tkm org accounts create \ --name \ --email \ [--iam-user-access-to-billing ] \ [--role-name ] \ [--alias ] \ [--ou ] \ [--config-file ] ``` ## Positional arguments This command has no positional arguments. ## Options In addition to the [common options](https://docs.takomo.io/command-line-usage/common-options), this command has the following options. * `--name ` * The friendly name of the member account. * Required. * `--email ` * The email address of the owner to assign to the new member account. This email address must not already be associated with another AWS account. You must use a valid email address to complete account creation. You can't access the root user of the account or remove an account that was created with an invalid email address. * Required. * `--iam-user-access-to-billing ` * If set to true, the new account enables IAM users to access account billing information if they have the required permissions. Otherwise, only the root user of the new account can access account billing information. * Optional, defaults to true. * `--role-name ` * The name of an IAM role that AWS Organizations automatically preconfigures in the new member account. This role trusts the master account, allowing users in the master account to assume the role, as permitted by the master account administrator. The role has administrator permissions in the new member account. * Optional, defaults to OrganizationAccountAccessRole. * `--alias ` * The account alias to create. * Optional. * `--ou ` * Path to the organizational unit where the account should be added. * Optional, defaults to Root. * `--config-file ` * Path to a file containing account specific configuration. * Optional. ## IAM permissions These are the minimum IAM permissions required to run this command. ```yaml Statement: - Effect: Allow Action: - organizations:DescribeOrganization - organizations:CreateAccount - organizations:DescribeCreateAccountStatus - organizations:ListRoots - organizations:ListTargetsForPolicy - organizations:ListAWSServiceAccessForOrganization - organizations:DescribePolicy - organizations:ListPolicies - organizations:ListAccountsForParent - organizations:ListAccounts - organizations:DescribeOrganization - organizations:ListOrganizationalUnitsForParent - organizations:MoveAccount Resource: "*" ``` ## Examples Create a new account with email **** and name **example**. ```bash tkm org accounts create \ --email hello@example.com \ --name example ``` Create a new account to organiational unit Root/Examples. ```bash tkm org accounts create \ --email hello@example.com \ --name example \ --ou Root/Examples ``` # Create account alias Create account alias. ## Usage ```bash tkm org accounts create-alias \ --account-id \ --alias ``` ## Positional arguments This command has no positional arguments. ## Options In addition to the [common options](https://docs.takomo.io/command-line-usage/common-options), this command has the following options. * `--account-id ` * Account id. Required. * `--alias ` * Account alias to create. Required. ## IAM permissions These are the minimum IAM permissions required to run this command. ```yaml # Permission needed to assume a role from the target account # used to create the account alias. Statement: - Effect: Allow Action: sts:AssumeRole Resource: "*" ``` The role in the target account must have the following permissions. ```yaml Statement: - Effect: Allow Action: iam:CreateAccountAlias Resource: "*" ``` ## Examples Create account alias ```bash tkm org accounts create-alias \ --account-id 123456789012 \ --alias my-account-alias ``` # Delete account alias Delete account alias. ## Usage ```bash tkm org accounts delete-alias \ --account-id ``` ## Positional arguments This command has no positional arguments. ## Options In addition to the [common options](https://docs.takomo.io/command-line-usage/common-options), this command has the following options. * `--account-id ` * Account id. Required. ## IAM permissions These are the minimum IAM permissions required to run this command. ```yaml # Permission needed to assume a role from the target account # used to delete the account alias. Statement: - Effect: Allow Action: sts:AssumeRole Resource: "*" ``` The role in the target account must have the following permissions. ```yaml Statement: - Effect: Allow Action: - iam:DeleteAccountAlias - iam:ListAccountAliases Resource: "*" ``` ## Examples Delete account alias: ```bash tkm org accounts delete-alias --account-id 123456789012 ``` # List accounts List accounts. ## Usage ```bash tkm org accounts list ``` ## Positional arguments This command has no positional arguments. ## Options In addition to the [common options](https://docs.takomo.io/command-line-usage/common-options), this command has no command-specific options. ## IAM permissions These are the minimum IAM permissions required to run this command. ```yaml Statement: - Effect: Allow Action: - organizations:DescribeOrganization - organizations:ListAccounts Resource: "*" ``` ## Examples List accounts. ```bash tkm org accounts list ``` # Account stacks Here are the account stacks commands: * [List accounts stacks](/command-line-usage/account-stacks/list-accounts-stacks) * [Deploy accounts](/command-line-usage/account-stacks/deploy-accounts) * [Undeploy accounts](/command-line-usage/account-stacks/undeploy-accounts) * [Bootstrap accounts](/command-line-usage/account-stacks/bootstrap-accounts) * [Tear down accounts](/command-line-usage/account-stacks/tear-down-accounts) # List accounts stacks List stacks from accounts. ## Usage ```bash tkm org accounts list-stacks [ou-path...] \ --config-set-type \ [--account ]... \ [--concurrent-accounts ] \ [--config-set ] \ [--command-path ] ``` ## Positional arguments * `ou-path...` * You can pass one or more organizational unit paths to list stacks only from the accounts that belong to the organizational units located under the given paths in the organization hierarchy. ## Options In addition to the [common options](https://docs.takomo.io/command-line-usage/common-options), this command has the following options. * `--config-set-type ` * List stacks that belong to a config sets of this type. * The provided config set type must be either **standard** or **bootstrap**. * `--account | -a ` * Choose accounts to from where to list stacks. You can use this option multiple times to specify more accounts. * `--concurrent-accounts ` * Number of accounts to process concurrently. * `--config-set ` * List only stacks that belong to this config set. * Optional. * `--command-path ` * List only stacks under this command path in the config set specified with the `--config-set` option. * Optional. * To use this option, also the `--config-set` option must be given. ## IAM permissions These are the minimum IAM permissions required to run this command. ```yaml Statement: # IAM permissions required for the organization master account. - Action: - organizations:DescribeOrganization - organizations:DescribePolicy - organizations:ListAWSServiceAccessForOrganization - organizations:ListAccounts - organizations:ListAccountsForParent - organizations:ListOrganizationalUnitsForParent - organizations:ListPolicies - organizations:ListRoots - organizations:ListTargetsForPolicy Effect: Allow Resource: '*' Sid: organizations - Action: - sts:AssumeRole Effect: Allow Resource: '*' Sid: sts # IAM permissions required in each organization account. - Sid: IAM Effect: Allow Action: - sts:AssumeRole - cloudformation:ListStacks Resource: "*" ``` ## Examples List stacks from every account. ```bash tkm org accounts list-stacks --config-set-type standard ``` List stacks from accounts that belong to the Root/Workload organizational unit. ```bash tkm org accounts list-stacks ROOT/Workload --config-set-type standard ``` List all stacks from accounts 123456789012 and 210987654321 ```bash tkm org accounts list-stacks \ -a 123456789012 210987654321 \ --config-set-type standard ``` List stacks from every account that belong to bootstrap config sets. ```bash tkm org accounts list-stacks --config-set-type bootstrap ``` # Deploy accounts Deploy infrastructure configured with config sets to the specified organizational units and accounts. ## Usage ```bash tkm org accounts deploy [ou-path...] \ [--account ]... \ [--concurrent-accounts ] \ [--config-set ] \ [--command-path ] ``` ## Positional arguments * `ou-path...` * You can pass one or more organizational unit paths to deploy only the accounts that belong to organizational units located under the given paths in the organization hierarchy. ## Options In addition to the [common options](https://docs.takomo.io/command-line-usage/common-options), this command has the following options. * `--account ` * Choose accounts to deploy. You can use this option multiple times to specify more accounts. * `--concurrent-accounts ` * Number of accounts to deploy concurrently. * `--config-set ` * Teardown only this config set. * Optional. * `--command-path ` * Teardown only stacks under this command path. * Optional. * To use this option, also the `--config-set` option must be given. ## IAM permissions These are the minimum IAM permissions required to run this command. ```yaml Statement: - Effect: Allow Action: - organizations:ListRoots - organizations:ListTargetsForPolicy - organizations:ListAWSServiceAccessForOrganization - organizations:DescribePolicy - organizations:ListPolicies - organizations:ListAccountsForParent - organizations:ListAccounts - organizations:DescribeOrganization - organizations:ListOrganizationalUnitsForParent Resource: "*" # IAM permissions needed to assume role from the target accounts. # Specify resource to restrict access to specific roles. - Sid: IAM Effect: Allow Action: - sts:AssumeRole Resource: "*" ``` ## Examples Deploy all accounts in the organization. ```bash tkm org accounts deploy ``` Deploy only accounts that belong to the organizational unit **Root/Sandbox** or to any organizational units under it. ```bash tkm org accounts deploy Root/Sandbox ``` Deploy only accounts that belong to the organizational unit **Root/Apps/Dev** or **Root/Apps/Test**, or to any organizational units under them. ```bash tkm org accounts deploy Root/Apps/Dev Root/Apps/Test ``` Deploy only account **123456789012**. ```bash tkm org accounts deploy --account 123456789012 ``` Deploy only account **123456789012** and **777777777777**. ```bash tkm org accounts deploy \ --account 123456789012 \ --account 777777777777 ``` # Undeploy accounts Remove infrastructure configured with config sets to the specified organizational units and accounts. ## Usage ```bash tkm org accounts undeploy [ou-path...] \ [--account ]... \ [--concurrent-accounts ] \ [--config-set ] \ [--command-path ] ``` ## Positional arguments * `ou-path...` * You can pass one or more organizational unit paths to undeploy only the accounts that belong to organizational units located under the given paths in the organization hierarchy. ## Options In addition to the [common options](https://docs.takomo.io/command-line-usage/common-options), this command has the following options. * `--account ` * Choose accounts to undeploy. You can use this option multiple times to specify more accounts. * `--concurrent-accounts ` * Number of accounts to undeploy concurrently. * `--config-set ` * Undeploy only this config set. * Optional. * `--command-path ` * Undeploy only stacks under this command path. * Optional. * To use this option, also the `--config-set` option must be given. ## IAM permissions These are the minimum IAM permissions required to run this command. ```yaml Statement: - Effect: Allow Action: - organizations:ListRoots - organizations:ListTargetsForPolicy - organizations:ListAWSServiceAccessForOrganization - organizations:DescribePolicy - organizations:ListPolicies - organizations:ListAccountsForParent - organizations:ListAccounts - organizations:DescribeOrganization - organizations:ListOrganizationalUnitsForParent Resource: "*" # IAM permissions needed to assume role from the target accounts. # Specify resource to restrict access to specific roles. - Sid: IAM Effect: Allow Action: - sts:AssumeRole Resource: "*" ``` ## Examples Undeploy all accounts in the organization. ```bash tkm org accounts undeploy ``` Undeploy only accounts that belong to the organizational unit **Root/Sandbox** or to any organizational units under it. ```bash tkm org accounts undeploy Root/Sandbox ``` Undeploy only accounts that belong to the organizational unit **Root/Apps/Dev** or **Root/Apps/Test**, or to any organizational units under them. ```bash tkm org accounts undeploy Root/Apps/Dev Root/Apps/Test ``` Undeploy only account **123456789012**. ```bash tkm org accounts undeploy --account 123456789012 ``` Undeploy only account **123456789012** and **777777777777**. ```bash tkm org accounts undeploy \ --account 123456789012 \ --account 777777777777 ``` # Bootstrap accounts Bootstrap infrastructure configured with config sets to the specified organizational units and accounts. ## Usage ```bash tkm org accounts bootstrap [ou-path...] \ [--account ]... \ [--concurrent-accounts ] \ [--config-set ] \ [--command-path ] ``` ## Positional arguments * `ou-path...` * You can pass one or more organizational unit paths to bootstrap only the accounts that belong to organizational units located under the given paths in the organization hierarchy. ## Options In addition to the [common options](https://docs.takomo.io/command-line-usage/common-options), this command has the following options. * `--account ` * Choose accounts to bootstrap. You can use this option multiple times to specify more accounts. * `--concurrent-accounts ` * Number of accounts to bootstrap concurrently. * `--config-set ` * Bootstrap only this config set. * Optional. * `--command-path ` * Bootstrap only stacks under this command path. * Optional. * To use this option, also the `--config-set` option must be given. ## IAM permissions These are the minimum IAM permissions required to run this command. ```yaml Statement: - Effect: Allow Action: - organizations:ListRoots - organizations:ListTargetsForPolicy - organizations:ListAWSServiceAccessForOrganization - organizations:DescribePolicy - organizations:ListPolicies - organizations:ListAccountsForParent - organizations:ListAccounts - organizations:DescribeOrganization - organizations:ListOrganizationalUnitsForParent Resource: "*" # IAM permissions needed to assume role from the target accounts. # Specify resource to restrict access to specific roles. - Sid: IAM Effect: Allow Action: - sts:AssumeRole Resource: "*" ``` ## Examples Bootstrap all accounts in the organization. ```bash tkm org accounts bootstrap ``` Bootstrap only accounts that belong to the organizational unit **Root/Sandbox** or to any organizational units under it. ```bash tkm org accounts bootstrap Root/Sandbox ``` # Tear down accounts Tear down infrastructure configured with config sets to the specified organizational units and accounts. ## Usage ```bash tkm org accounts tear-down [ou-path...] \ [--account ]... \ [--concurrent-accounts ] \ [--config-set ] \ [--command-path ] ``` ## Positional arguments * `ou-path...` * You can pass one or more organizational unit paths to tear down only the accounts that belong to organizational units located under the given paths in the organization hierarchy. ## Options In addition to the [common options](https://docs.takomo.io/command-line-usage/common-options), this command has the following options. * `--account ` * Choose accounts to tear down. You can use this option multiple times to specify more accounts. * `--concurrent-accounts ` * Number of accounts to tear down concurrently. * `--config-set ` * Teardown only this config set. * Optional. * `--command-path ` * Teardown only stacks under this command path. * Optional. * To use this option, also the `--config-set` option must be given. ## IAM permissions These are the minimum IAM permissions required to run this command. ```yaml Statement: - Effect: Allow Action: - organizations:ListRoots - organizations:ListTargetsForPolicy - organizations:ListAWSServiceAccessForOrganization - organizations:DescribePolicy - organizations:ListPolicies - organizations:ListAccountsForParent - organizations:ListAccounts - organizations:DescribeOrganization - organizations:ListOrganizationalUnitsForParent Resource: "*" # IAM permissions needed to assume role from the target accounts. # Specify resource to restrict access to specific roles. - Sid: IAM Effect: Allow Action: - sts:AssumeRole Resource: "*" ``` ## Examples Tear down all accounts in the organization. ```bash tkm org accounts tear-down ``` Tear down only accounts that belong to the organizational unit **Root/Sandbox** or to any organizational units under it. ```bash tkm org accounts tear-down Root/Sandbox ```