Ensure complete project audit-log forwarding and restrict routing changes with STACKIT IAM #99

Problem

The accelerator already provisions a central Telemetry Router in the management project, an OTLP destination backed by STACKIT Logs, an S3 archive destination, and the required credentials.

However, enabling audit_logs without specifying link_scopes creates only an organization-level Telemetry Link. The variable description and example comments describe this as organization-wide routing. According to the current STACKIT documentation, Telemetry Links capture events for their associated resource only and do not inherit to child folders or projects. Consequently, the default does not capture workload-project audit events.

Explicit project/folder scopes are supported, but are not automatically derived from the resources created by the accelerator. Newly provisioned projects can therefore remain disconnected from the central audit pipeline.

There is also no audit-specific permission boundary: landing-zone automation service accounts receive project owner, while the management automation service account receives organization owner. A principal with those effective permissions can change routing or grant itself the necessary permissions. Adding a restricted custom role does not remove permissions granted by another binding.

Relevant implementation:

• src/modules/management/6-audit-logs.tf
• src/modules/landing-zone/2-rbac.tf
• src/modules/management/4-service-account.tf
• src/variables.tf

Proposed scope: supported STACKIT capabilities

1. Complete the link coverage

• Provide an explicit full-coverage mode that creates a Telemetry Link for every relevant accelerator-managed project, including platform projects and sandboxes, plus links for the organization and managed folders to collect their own events.
• Derive resource IDs from module outputs so that new projects are connected as part of provisioning, without maintaining a separate manual ID list.
• Preserve explicit link_scopes for intentional partial coverage or existing resources. Document how this mode interacts with automatic coverage and existing links; avoid duplicate links.
• Respect the STACKIT constraint of one link per resource per region and a router in the same region. Either support additional regional routers or clearly reject unsupported cross-region configurations.
• Correct the organization-wide/inheritance claims in variable descriptions, examples, and generated documentation.

2. Restrict routing changes through IAM

• Provide a documented, configurable role pattern for application users and workload automation accounts using product-specific roles or custom permission allowlists, without blanket owner or unreviewed editor grants.
• Reserve Telemetry Link mutation rights for the central platform/security identity. Application identities must not be able to disable, delete, or redirect their project's link.
• Exclude privilege-escalation permissions from application roles, especially iam.member.add, iam.role.add, and iam.role.edit. Account for direct, group, and inherited bindings; an additional restrictive role cannot override an existing grant.
• Keep router/destination/token management and central Logs, archive, and administrative credentials inaccessible to application identities. Address access to privileged service-account keys and federation configuration as part of this boundary.
• Use a central administrative identity for the required project-creation owner where applicable. This issue does not require owner-less project creation. Expose the workload automation role as a configurable choice instead of unconditionally granting project owner; document compatibility and migration for existing deployments.

Acceptance criteria

• A representative organization/folder/project deployment produces the expected resource-specific links, all pointing to the correct regional central router. Provisioning an additional project creates its link automatically.
• A newly triggered project-level audit event can be queried in central STACKIT Logs and is delivered to the S3 archive.
• Using a representative application identity, attempts to update, disable, delete, or redirect a Telemetry Link are denied; required workload operations still succeed.
• The same identity cannot grant itself stronger roles, modify its role's permissions, or obtain/use the privileged central automation identity. Inherited grants are explicitly covered by the deployment guidance and validation.
• The designated central identity can manage the links and destinations. The existing disabled and explicit-scope modes remain usable, with migration behavior documented.
• Add meaningful Terraform/OpenTofu regression coverage for scope generation and configurable workload role assignments, plus a documented live IAM/data-flow validation procedure.

Supported security boundary

The goal is to prevent changes by application identities that lack the relevant permissions. STACKIT IAM is additive: inherited access must be removed at its source, and project-level bindings cannot deny it. This issue does not request a deny policy, an immutable routing setting, or protection against administrators who retain effective owner/IAM administration rights. Object Lock protects archived objects, not forwarding configuration; Terraform drift detection alone does not prevent API or Portal changes.

References and related issues

• STACKIT Telemetry Links: no hierarchy inheritance and regional constraints
• STACKIT IAM: additive access and inherited role bindings
• STACKIT custom roles and privilege-escalation permissions
• Telemetry Link Admin requirement
• Implement Audit/Activity logs #16 implemented the initial audit/activity-log pipeline.
• Create projects without default owner role #69 tracks owner-less project creation separately; this issue does not depend on that capability.
• Align audit log Object Lock defaults with documentation and test omitted values #81 tracks the Object Lock default/documentation mismatch separately; it is not duplicated here.