Misc documentation fixes (#493)
This commit is contained in:
Simone Ruffilli
GitHub
parent
6c1c943600
commit
1aa5d5d93f
|
|
@ -1,6 +1,6 @@
|
|||
# Organization bootstrap
|
||||
|
||||
The primary purpose of this stage is to enable critical organization-level functionality that depends on broad administrative permissions, and prepare the prerequisites needed to enable automation in this and future stages.
|
||||
The primary purpose of this stage is to enable critical organization-level functionalities that depend on broad administrative permissions, and prepare the prerequisites needed to enable automation in this and future stages.
|
||||
|
||||
It is intentionally simple, to minimize usage of administrative-level permissions and enable simple auditing and troubleshooting, and only deals with three sets of resources:
|
||||
|
||||
|
|
@ -28,7 +28,7 @@ We have standardized the initial set of groups on those outlined in the [GCP Ent
|
|||
|
||||
### Organization-level IAM
|
||||
|
||||
The service account used in the [Resource Management stage](../01-resman) needs to be able to grant specific roles at the organizational level (`roles/billing.user`, `roles/compute.xpnAdmin`, etc.), to enable specific functionality for subsequent stages that deal with network or security resources, or billing-related activities.
|
||||
The service account used in the [Resource Management stage](../01-resman) needs to be able to grant specific permissions at the organizational level, to enable specific functionality for subsequent stages that deal with network or security resources, or billing-related activities.
|
||||
|
||||
In order to be able to assign those roles without having the full authority of the Organization Admin role, this stage defines a custom role that only allows setting IAM policies on the organization, and grants it via a [delegated role grant](https://cloud.google.com/iam/docs/setting-limits-on-granting-roles) that only allows it to be used to grant a limited subset of roles.
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ To quickly self-grant the above roles, run the following code snippet as the ini
|
|||
```bash
|
||||
export BOOTSTRAP_ORG_ID=123456
|
||||
export BOOTSTRAP_USER=$(gcloud config list --format 'value(core.account)')
|
||||
export BOOTSTRAP_ROLES=(roles/billing.admin roles/logging.admin roles/iam.organizationRoleAdmin roles/resourcemanager.projectCreator)
|
||||
export BOOTSTRAP_ROLES="roles/billing.admin roles/logging.admin roles/iam.organizationRoleAdmin roles/resourcemanager.projectCreator"
|
||||
for role in $BOOTSTRAP_ROLES; do
|
||||
gcloud organizations add-iam-policy-binding $BOOTSTRAP_ORG_ID \
|
||||
--member user:$BOOTSTRAP_USER --role $role
|
||||
|
|
@ -146,10 +146,10 @@ Before the first run, the following IAM groups must exist to allow IAM bindings
|
|||
|
||||
#### Configure variables
|
||||
|
||||
Then make sure you have configured the correct values for the following variables by editing providing a `terraform.tfvars` file:
|
||||
Then make sure you have configured the correct values for the following variables by providing a `terraform.tfvars` file:
|
||||
|
||||
- `billing_account`
|
||||
an object containing the id of your billing account, derived from the Cloud Console UI or by running `gcloud beta billing accounts list`, and the id of the organization owning it, or `null` to use the billing account in isolation
|
||||
an object containing `id` as the id of your billing account, derived from the Cloud Console UI or by running `gcloud beta billing accounts list`, and `organization_id` as the id of the organization owning it, or `null` to use the billing account in isolation
|
||||
- `groups`
|
||||
the name mappings for your groups, if you're following the default convention you can leave this to the provided default
|
||||
- `organization.id`, `organization.domain`, `organization.customer_id`
|
||||
|
|
@ -157,6 +157,25 @@ Then make sure you have configured the correct values for the following variable
|
|||
- `prefix`
|
||||
the fixed prefix used in your naming convention
|
||||
|
||||
You can also adapt the example that follows to your needs:
|
||||
|
||||
```hcl
|
||||
# fetch the required id by running `gcloud beta billing accounts list`
|
||||
billing_account={
|
||||
id="012345-67890A-BCDEF0"
|
||||
organization_id="01234567890"
|
||||
}
|
||||
# get the required info by running `gcloud organizations list`
|
||||
organization={
|
||||
id="01234567890"
|
||||
domain="fast.example.com"
|
||||
customer_id="Cxxxxxxx"
|
||||
}
|
||||
# create your own 4-letters prefix
|
||||
prefix="fast"
|
||||
outputs_location = "../../fast-config"
|
||||
```
|
||||
|
||||
### Output files and cross-stage variables
|
||||
|
||||
At any time during the life of this stage, you can configure it to automatically generate provider configurations and variable files for the following, to simplify exchanging inputs and outputs between stages and avoid having to edit files manually.
|
||||
|
|
@ -180,8 +199,6 @@ Below is the outline of the output files generated by this stage:
|
|||
│ ├── terraform-bootstrap.auto.tfvars.json
|
||||
├── 02-networking
|
||||
│ ├── terraform-bootstrap.auto.tfvars.json
|
||||
├── 02-networking-nva
|
||||
│ ├── terraform-bootstrap.auto.tfvars.json
|
||||
├── 02-security
|
||||
│ ├── terraform-bootstrap.auto.tfvars.json
|
||||
├── 03-gke-multitenant-dev
|
||||
|
|
@ -216,7 +233,7 @@ terraform output -json providers | jq -r '.["00-bootstrap"]' \
|
|||
> providers.tf
|
||||
# migrate state to GCS bucket configured in providers file
|
||||
terraform init -migrate-state
|
||||
# run terraform apply to remo user iam binding
|
||||
# run terraform apply to remove the bootstrap_user iam binding
|
||||
terraform apply
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ terraform output -json providers | jq -r '.["01-resman"]' \
|
|||
> ../01-resman/providers.tf
|
||||
```
|
||||
|
||||
If you want to continue to rely on `outputs_location` logic, create a `terraform.tfvars` file and configure it as deacribed [here](../00-bootstrap/#output-files-and-cross-stage-variables).
|
||||
If you want to continue to rely on `outputs_location` logic, create a `terraform.tfvars` file and configure it as described [here](../00-bootstrap/#output-files-and-cross-stage-variables).
|
||||
|
||||
### Variable configuration
|
||||
|
||||
|
|
@ -177,12 +177,12 @@ Due to its simplicity, this stage lends itself easily to customizations: adding
|
|||
|
||||
| name | description | sensitive | consumers |
|
||||
|---|---|:---:|---|
|
||||
| [networking](outputs.tf#L88) | Data for the networking stage. | | <code>02-networking</code> |
|
||||
| [project_factories](outputs.tf#L98) | Data for the project factories stage. | | <code>xx-teams</code> |
|
||||
| [providers](outputs.tf#L115) | Terraform provider files for this stage and dependent stages. | ✓ | <code>02-networking</code> · <code>02-security</code> · <code>xx-sandbox</code> · <code>xx-teams</code> |
|
||||
| [sandbox](outputs.tf#L122) | Data for the sandbox stage. | | <code>xx-sandbox</code> |
|
||||
| [security](outputs.tf#L132) | Data for the networking stage. | | <code>02-security</code> |
|
||||
| [teams](outputs.tf#L142) | Data for the teams stage. | | |
|
||||
| [tfvars](outputs.tf#L155) | Terraform variable files for the following stages. | ✓ | |
|
||||
| [networking](outputs.tf#L83) | Data for the networking stage. | | <code>02-networking</code> |
|
||||
| [project_factories](outputs.tf#L93) | Data for the project factories stage. | | <code>xx-teams</code> |
|
||||
| [providers](outputs.tf#L110) | Terraform provider files for this stage and dependent stages. | ✓ | <code>02-networking</code> · <code>02-security</code> · <code>xx-sandbox</code> · <code>xx-teams</code> |
|
||||
| [sandbox](outputs.tf#L117) | Data for the sandbox stage. | | <code>xx-sandbox</code> |
|
||||
| [security](outputs.tf#L127) | Data for the networking stage. | | <code>02-security</code> |
|
||||
| [teams](outputs.tf#L137) | Data for the teams stage. | | |
|
||||
| [tfvars](outputs.tf#L150) | Terraform variable files for the following stages. | ✓ | |
|
||||
|
||||
<!-- END TFDOC -->
|
||||
|
|
|
|||
|
|
@ -25,11 +25,6 @@ locals {
|
|||
name = "networking"
|
||||
sa = module.branch-network-sa.email
|
||||
})
|
||||
"02-networking-nva" = templatefile("${path.module}/../../assets/templates/providers.tpl", {
|
||||
bucket = module.branch-network-gcs.name
|
||||
name = "networking-nva"
|
||||
sa = module.branch-network-sa.email
|
||||
})
|
||||
"02-security" = templatefile("${path.module}/../../assets/templates/providers.tpl", {
|
||||
bucket = module.branch-security-gcs.name
|
||||
name = "security"
|
||||
|
|
|
|||
|
|
@ -187,12 +187,13 @@ If you have set a valid value for `outputs_location` in the bootstrap and in the
|
|||
ln -s ../../configs/example/02-networking/terraform-bootstrap.auto.tfvars.json
|
||||
ln -s ../../configs/example/02-networking/terraform-resman.auto.tfvars.json
|
||||
```
|
||||
If you want to continue to rely on `outputs_location` logic, create a `terraform.tfvars` file and configure it as described [here](../00-bootstrap/#output-files-and-cross-stage-variables).
|
||||
|
||||
Please, refer to the [variables](#variables) table below for a map of the variable origins, and use the sections below to understand how to adapt this stage to your networking configuration.
|
||||
|
||||
### VPCs
|
||||
|
||||
VPCs are defined in separate files, one for `untrusted landing`, one for `trusted landing`, one for `prod` and one for `dev`.
|
||||
VPCs are defined in separate files, one for `landing` (trusted and untrusted), one for `prod` and one for `dev`.
|
||||
|
||||
These files contain different resources:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue