feat: trust GitHub immutable OIDC subjects in the deploy role

[dannysteenman]

Summary

The deploy role trusted repo:OWNER/REPOSITORY:*, a subject built from names alone. Rename a repository, or delete and recreate one under the same name, and the trust follows the name instead of the repository. This moves the trust policy to GitHub's immutable subject claim:

repo:OWNER@OWNER-ID/REPOSITORY@REPOSITORY-ID:*

Matches the change in the TypeScript starter kit.

aws-cdk-github-oidc goes away with it. GithubActionsRole builds the legacy name-only subject and gives you no way to opt out, so the stack now uses aws-cdk-lib IAM constructs directly. It still imports the account's existing OIDC provider rather than creating one, so the synthesized template holds the same resources as before, with only the subject changed. Diffed the two templates to confirm.

src/bin/git_helper.py resolves the repository identity: in GitHub Actions from the default GITHUB_REPOSITORY, GITHUB_REPOSITORY_ID, and GITHUB_REPOSITORY_OWNER_ID variables, and locally from the origin remote plus gh api. No workflow needs a GitHub token.

The subject lands in an IAM StringLike condition, so build_github_actions_oidc_subject raises on a malformed field rather than rendering it. An id of * would otherwise widen the policy to every repository sharing that name.

GitHubOIDCStack picks up two optional arguments:

• additional_repositories: other repositories under the same owner, each with its numeric GitHub ID (gh api repos/OWNER/NAME --jq .id). Checked in rather than looked up, because a lookup would hand every synthesizing CI job a token able to read the other repository.
• subject_context: defaults to *, matching what the stack trusted before. Narrow it to environment:production once the deploy workflows declare a GitHub environment.

Drive-by fix

pytest couldn't import anything under src, so all 3 test modules failed to collect, including the pre-existing test_example.py. The CDK app entrypoint lives in src, so Python puts that directory on sys.path at runtime, but pytest collects from the repository root. Setting tool.pytest.ini_options.pythonpath through .projenrc.py gives it the same import root.

There's no build workflow in this repo, so nothing was running pytest to catch it.

Re-synth also revealed the pytest pin had drifted: pyproject.toml said 9.0.3 while .projenrc.py used projen's 7.4.3 default. Pinned it in .projenrc.py so the generated file matches.

Cutover

A repository keeps emitting the legacy subject until it's opted in, and there's no fallback. Deploy the stack first, then:

gh api -X PUT repos/OWNER/REPOSITORY/actions/oidc/customization/sub -F use_default=true -F use_immutable_subject=true

Reverse that order and GitHub issues a subject the deployed role rejects.

Diagram

flowchart LR
  Actions["GitHub Actions default variables"] --> Resolver["get_git_repository_identity()"]
  Git["origin remote + gh api"] --> Resolver
  Resolver --> Subject["build_github_actions_oidc_subject()"]
  Extra["additional_repositories: name + numeric id"] --> Subject
  Subject --> Role["GitHubDeployRole trust policy"]

Loading

Validation

• uv run projen build, 27 tests green (1 before this branch, and it was failing to collect)
• uv run ty check src/ clean
• uv run cdk synth against this checkout renders repo:towardsthecloud@200249707/aws-cdk-python-starter-kit@775652363:*, resolved through gh api
• Stack tests pin a fake repository identity through the environment variables, so they don't shell out to git or read whichever checkout they run in