# common_services_roles module

Creates "standard" IAM policies and roles in an account being treated like an
AWS organizations hierarchy root.

Picture our collection of AWS accounts with the "common-services"
account being the root of an Organizations hierarchy, where all of the users
exist there and AssumeRole to the correct role in the child account

```java
common-services
    prod-c2
    test-c2
    prod-customer-1
    prod-customer-2
    ...
```

This module makes one SAML-linked role `mdr_engineer_readonly` that we
access via OKTA.  From there you AssumeRole into `mdr_terraformer` to make
changes - either in this account or in others.  Or, you AssumeRole into 
`mdr_engineer_readonly` in the other accounts for "just browsing".

Make sure you have an `OKTA_API_TOKEN` enviornment variable set with
an Okta API token.

## Providers

| Name | Version |
|------|---------|
| aws  | ~2.0?   |
| okta | ?       |

## Inputs

| Name | Description | Type | Required |
|------|-------------|------|----------|
| okta_app | The (friendly) name of the Okta app.  In our environment either "AWS - Commercial" or "AWS - GovCloud" | `string` | Yes |
| account_alias | The account alias that should be set for the AWS account.  This is an AWS global value | `string` | yes |

## Roles created

| Role Name         | Attached Policies | Description |
|--------------------|-------------------|-------------|
| /user/mdr\_engineer\_readonly | ReadOnlyAccess <br> mdr\_engineer\_readonly\_assumerole | Read only access to AWS console with ability to escalate to Terraformer role
| /user/mdr\_terraformer| mdr\_terraformer | Full read/write access to (almost) everything.  Has some limitations around PassRole and AssumeRole

## Modules referenced

| Module name            | purpose |
|------------------------|---------|
| standard_iam_policies  | defines the policies used by the roles  |
| saml_linked_role       | submodule that defines the okta group and role        |