Resource Control Policies

This RCP denies any request to S3, STS, KMS, SQS, Secrets Manager, Cognito, CloudWatch Logs, DynamoDB, ECR, and OpenSearch Serverless resources that doesn't use TLS, org-wide, at the resource layer — a guarantee an SCP alone cannot make, since a resource-based policy could otherwise still permit plaintext HTTP regardless of principal-side controls.

This RCP denies Amazon S3 API calls made with a TLS version below 1.2, enforced at the resource layer — a narrower, S3-specific companion to the org-wide HTTPS-only RCP.

This RCP denies `s3:PutObject` requests that supply a customer-provided (SSE-C) encryption key, forcing all object encryption through the organization's centrally managed KMS keys instead of caller-supplied key material that AWS never stores and that security tooling cannot inspect.

This RCP denies S3 requests signed with a SigV4 signature older than a configured maximum age, limiting how long a leaked presigned URL remains usable — a resource-side control that holds even if the URL was generated by a principal outside the organization's direct control.

This RCP denies `s3:PutAccountPublicAccessBlock` outside a privileged role — the resource-side counterpart to a principal-side SCP restricting the same action, closing the gap where a resource policy or cross-account actor could otherwise still touch the account's S3 Block Public Access setting.

This RCP denies `kms:ScheduleKeyDeletion`, `kms:DeleteAlias`, `kms:DeleteCustomKeyStore`, and `kms:DeleteImportedKeyMaterial` outside a privileged role at the resource layer, complementing the library's existing principal-side `scp_kms_delete_keys` SCP.

This RCP denies `sts:AssumeRoleWithWebIdentity` unless the GitHub Actions OIDC token's `sub` claim matches an allowlisted GitHub organization, locking OIDC trust down at the resource (role trust) layer so it can't be bypassed by adding a new role with a looser trust policy.

This RCP denies access to resources belonging to a given OU unless the caller is also a principal from that same OU (or an AWS service), enforcing an intra-org boundary — for example, keeping a "development" OU's S3, SQS, KMS, Secrets Manager, CloudWatch Logs, DynamoDB, and ECR resources unreachable from principals outside that OU.