Trusted Access

src/config/service-integrations/trusted-access.ts declares which AWS services get trusted access to your AWS Organization. Trusted access lets an AWS service read your organization structure and operate across member accounts on your behalf, and it is the prerequisite for org-wide features like the organization trail, GuardDuty, Security Hub, Resource Explorer, and StackSets. The organization phase (LandingZoneOrganizationStack) reads this file and enables trusted access for each listed service before anything that depends on it runs.

The file exports a single trustedAccess object. Keep the list limited to the services the landing zone actually configures. Enabling trusted access for a service you do not use adds a service-linked integration you then have to remember to clean up.

Options

trustedAccess is a TrustedAccessProps. In the starter it sets enabled and an explicit services list, but the type also supports adjusting the built-in defaults without copying them.

Use the TrustedAccessAwsService constants for the principal values so they stay typo-resistant and autocomplete-friendly (for example TrustedAccessAwsService.SECURITY_HUB instead of the raw securityhub.amazonaws.com). The constants track the services in the AWS Organizations integrated-services table that support trusted access.

Example

The starter ships an explicit services list so what is enabled is visible at a glance rather than hidden behind a default:

export const trustedAccess = {
  enabled: true,
  services: [
    TrustedAccessAwsService.ACCOUNT,
    TrustedAccessAwsService.BACKUP,
    TrustedAccessAwsService.BILLING_COST_MANAGEMENT,
    TrustedAccessAwsService.CLOUDTRAIL,
    TrustedAccessAwsService.COMPUTE_OPTIMIZER,
    TrustedAccessAwsService.CONFIG_MULTI_ACCOUNT_SETUP,
    TrustedAccessAwsService.CONFIG,
    TrustedAccessAwsService.COST_OPTIMIZATION_HUB,
    TrustedAccessAwsService.EC2,
    TrustedAccessAwsService.GUARDDUTY,
    TrustedAccessAwsService.HEALTH,
    TrustedAccessAwsService.IAM,
    TrustedAccessAwsService.IAM_ACCESS_ANALYZER,
    TrustedAccessAwsService.INSPECTOR,
    TrustedAccessAwsService.MACIE,
    TrustedAccessAwsService.GUARDDUTY_MALWARE_PROTECTION,
    TrustedAccessAwsService.CLOUDFORMATION_STACKSETS_MEMBER,
    TrustedAccessAwsService.USER_NOTIFICATIONS,
    TrustedAccessAwsService.RAM,
    TrustedAccessAwsService.TRUSTED_ADVISOR,
    TrustedAccessAwsService.RESOURCE_EXPLORER,
    TrustedAccessAwsService.SECURITY_HUB,
    TrustedAccessAwsService.SERVICE_QUOTAS,
    TrustedAccessAwsService.SSM,
    TrustedAccessAwsService.TAG_POLICIES,
  ],
} satisfies TrustedAccessProps;

To add a service without restating the whole list, drop the explicit services array and use additionalServices:

export const trustedAccess = {
  enabled: true,
  additionalServices: [TrustedAccessAwsService.FIREWALL_MANAGER],
} satisfies TrustedAccessProps;

How it's used

LandingZoneOrganizationStack passes trustedAccess into OrganizationConstruct, which enables trusted service access for each principal at the organization root. Because it runs in the organization phase, trusted access is in place before the landing-zone phase deploys any StackSet or before delegated-admins.ts registers a delegated administrator: AWS requires a service's trusted access to be enabled before you can delegate its administration.

Keep this file aligned with delegated-admins.ts. Every service you delegate needs matching trusted access here. The starter's FinOps account is the delegated administrator for Compute Optimizer, Cost Optimization Hub, and Resource Explorer, so those three have trusted access enabled. AWS User Notifications is enabled too, so AWS managed notifications for the organization can be aggregated in the observability account, its delegated administrator. The default config enables IAM and IAM Access Analyzer trusted access and delegates both to the security account, so the Organization Security StackSet can enable IAM centralized root access org-wide and create the organization external access analyzer from the security account.

For routine security-service enablement changes, edit security-services.ts. Keep delegation and trusted access configured when a capability is disabled so you can enable it again.

Things to know

• AWS IAM Identity Center (TrustedAccessAwsService.SSO) is not in the default list. Add it only if you want the landing zone to manage that integration.
• Removing a service disables its trusted access on the next deploy. Disabling trusted access for a security service has org-wide side effects, so treat removals the same way you treat removing a delegated administrator: confirm nothing still depends on the integration first.
• Disabling a security service does not need a trusted access change. Keep GuardDuty, Inspector, Macie, and Security Hub CSPM here when you set enabled: false in security-services.ts, so you can enable them again.
• Amazon EC2 trusted access supports the declarative policy. The starter's declarative policy needs it, so keep TrustedAccessAwsService.EC2 in the list while that policy is attached. Tag policies likewise rely on TrustedAccessAwsService.TAG_POLICIES.
• Keep the list to what you use. The comment in the file spells out every service enabled by default; add to it only when you adopt a new AWS Organizations integration.