You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 3138e40
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: CHANGELOG.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
7
7
8
8
## [Unreleased]
9
9
10
+
### Breaking
11
+
- Replace the singleton root role and assignment inputs with keyed `roles` and `subjects` collections. Roles can independently scope workflow groups, cloud connectors, VCS connectors, and templates; each subject assignment now carries its complete roles list.
12
+
10
13
### Added
11
14
- Add root-level AWS, Azure, and GCP identity wiring so Terraform creates the selected cloud identity and registers its generated identifiers with StackGuardian.
12
15
- Add CLI-authenticated AWS and Azure onboarding and guarded destroy tasks with temporary targeted plans and StackGuardian token prompting.
Copy file name to clipboardExpand all lines: README.md
+36-46Lines changed: 36 additions & 46 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
-
# StackGuardian Terraform Modules v2
1
+
# StackGuardian Terraform Modules
2
2
3
-
Terraform modules for StackGuardian onboarding and cloud identity configuration. The root module creates workflow groups, cloud/VCS connectors, a role, and one assignment. `stackguardian_private_runner/` is explicitly outside the v2 upgrade scope.
3
+
Terraform modules for StackGuardian onboarding and cloud identity configuration. The root module creates workflow groups, cloud/VCS connectors, keyed roles, and one multi-role assignment per subject.
4
4
5
5
## Prerequisites
6
6
@@ -9,23 +9,31 @@ Terraform modules for StackGuardian onboarding and cloud identity configuration.
9
9
- AWS provider `>= 6.58.0, < 7.0.0`, AzureRM `>= 5.0.1, < 6.0.0`, AzureAD `>= 3.9.0, < 4.0.0`, and Google `>= 7.44.0, < 8.0.0` in their applicable modules.
10
10
- Credentials authorized to create the selected cloud identities. Azure management needs Microsoft Graph application-management and subscription role-assignment privileges.
11
11
12
-
Use `terraform.tfvars.example` as a schema reference. Put secret values in `TF_VAR_*` variables or a secret manager, not version control.
12
+
Use `terraform.tfvars.example` as a configuration reference. Put secret values in `TF_VAR_*` variables or a secret manager, not version control.
13
13
14
-
## Static Credential Deprecation
14
+
## How To Use
15
15
16
-
`aws_static`, `azure_static`, and `AWS_STATIC` or `AZURE_STATIC` cloud connectors are deprecated. Static secrets are retained in Terraform state and may appear in plan artifacts, so protect both as sensitive data. Prefer `aws_rbac`, `aws_oidc`, `azure_oidc`, or the corresponding non-static connector kind.
16
+
1. Copy `terraform.tfvars.example` to an ignored `terraform.tfvars` file and replace its placeholders.
17
+
2. Set `TF_VAR_stackguardian_api_key` through a secret manager or environment variable.
18
+
3. Authenticate to each cloud used by `cloud_connectors`.
19
+
4. Run `terraform init`, review `terraform plan`, then run `terraform apply`.
20
+
21
+
For AWS and Azure OIDC onboarding, customize the matching file in `examples/` and use `task onboard:aws` or `task onboard:azure`. Those tasks authenticate through the local cloud CLI, create the selected cloud identity, and apply a reviewed plan.
22
+
23
+
## Static Credentials
24
+
25
+
`AWS_STATIC` and `AZURE_STATIC` are supported only when `allow_static_credentials = true` is set on that connector. Static secrets are retained in Terraform state and may appear in plan artifacts. Prefer `AWS_RBAC`, `AWS_OIDC`, `AZURE_OIDC`, or `GCP_OIDC` whenever possible.
17
26
18
27
Static authentication requires an explicit acknowledgement. The root acknowledgement is per connector and cannot enable another connector:
Standalone `aws_static` and `azure_static` modules also require `allow_static_credentials = true`. Terraform emits a deprecation warning during apply after acknowledgement.
@@ -42,25 +50,21 @@ Both onboarding tasks use `TF_VAR_stackguardian_api_key` when it is set. Otherwi
42
50
43
51
Use `task destroy:aws` or `task destroy:azure` to remove a connector trial. Each asks you to type the connector name before it destroys resources. AWS teardown retains any account-level `api.app.stackguardian.io` OIDC provider because it may be shared by multiple StackGuardian roles.
44
52
45
-
## V2 Inputs
46
-
47
-
| v1 input | v2 input |
48
-
| --- | --- |
49
-
|`api_key`|`stackguardian_api_key`|
50
-
|`org_name`|`stackguardian_org_name`|
51
-
|`user_or_group`|`subject`|
52
-
|`connector_type`|`kind` in `cloud_connectors`|
53
-
|`cloud_connector_name`|`name` in `cloud_connectors`|
54
-
|`aws_default_region`|`aws_region` in the AWS connector |
55
-
|`armTenantId`, `armSubscriptionId`, `armClientId`, `armClientSecret`|`azure_tenant_id`, `azure_subscription_id`, `azure_client_id`, `azure_client_secret` in the Azure connector |
|`gcp_oidc.project`, `sg-org-id`|`gcp_project_id` in the GCP connector, `stackguardian_org_name`|
62
-
63
-
Legacy aliases are intentionally unavailable. The root configures StackGuardian once; standalone StackGuardian leaf modules inherit provider configuration from their caller and do not accept API credentials.
53
+
## Onboarding Configuration
54
+
55
+
`terraform.tfvars.example` is a complete multi-role configuration. The root accepts these top-level collections:
56
+
57
+
-`workflow_groups`: unique names of workflow groups to create.
58
+
-`cloud_connectors`: a map keyed by connector name. Each value selects one cloud `kind` and supplies the corresponding identity settings. The root creates the selected identity and registers it with StackGuardian.
59
+
-`vcs_connectors`: a map keyed by connector name. Each value supplies one GitHub, GitLab, or Bitbucket credential configuration. Its `name` must match the map key.
60
+
-`roles`: a map keyed by StackGuardian role name. Each role references one or more workflow groups, cloud connectors, VCS connectors, or templates.
61
+
-`subjects`: a map keyed by a local email or qualified SSO subject. Each subject receives one or more role names in one assignment resource.
62
+
63
+
Role references use the corresponding collection keys. A role must include at least one non-empty scope. Empty scope categories produce no permissions.
64
+
65
+
Subjects can be local emails such as `developer@example.invalid`, qualified SSO emails such as `okta/developer@example.invalid`, or SSO groups such as `okta/platform-engineers`. `entity_type` defaults to `EMAIL`; set it to `GROUP` for a group. Role lists must be non-empty and duplicate-free.
66
+
67
+
VCS credentials remain sensitive and are stored in Terraform state. Keep real values in an ignored secret vars file, a generated `terraform.tfvars.json`, or JSON-encoded `TF_VAR_vcs_connectors`; examples use literal placeholders.
64
68
65
69
## Permissions And Defaults
66
70
@@ -71,20 +75,6 @@ Legacy aliases are intentionally unavailable. The root configures StackGuardian
71
75
- Cloud and VCS connector modules require access to create StackGuardian connectors. They reject missing, mismatched, or conflicting credentials.
72
76
- Role, assignment, and workflow-group modules require StackGuardian role-management permission.
73
77
74
-
## Role v4 State Migration
75
-
76
-
The role resource changes from `stackguardian_role` to `stackguardian_rolev4`; this cannot use a `moved` block or `terraform state mv`. During a maintenance window with exclusive backend locking, back up state and record the existing permissions, then run:
77
-
78
-
```bash
79
-
terraform state rm 'module.stackguardian_role.stackguardian_role.role'
For standalone role usage, omit `module.stackguardian_role.`. Review the v4 `allowed_permissions`, apply the reviewed update, then run a second plan and test an allowed and denied path. Do not use `state mv`; roll back only by restoring the backed-up state/configuration.
85
-
86
-
Before replacing the former authoritative GCP IAM policy, add and import `google_service_account_iam_member.self_workload_identity`, then remove only the old policy state binding. Likewise, import the existing AWS role-policy attachment when converting from the legacy global attachment. Export existing IAM bindings first and verify the plan cannot remove unrelated principals.
87
-
88
78
## Module Usage
89
79
90
80
Each module has a short usage and outputs reference in its directory README. Run `terraform init -upgrade`, `terraform validate`, and a reviewed plan from the specific module directory. Lock files are deliberately not committed because callers initialize independently.
0 commit comments