# IAM policies applied manually to the `github-actions` deploy role

The GitHub Actions OIDC role `arn:aws:iam::992382448282:role/github-actions` is
**not** managed by the Terraform in `infra/terraform/` — it's maintained by hand
in AWS IAM (see `README.md` → "AWS credentials are not stored as secrets … update
that role's trust policy and inline policies in AWS IAM"). Its inline policies are
resource-scoped to the existing `cube-mcp-*` resources, so **any Terraform change
that introduces a new resource type or name the role can't yet create will fail
`terraform apply` in CI with `AccessDenied` / `UnauthorizedOperation`.**

The JSON files here are the manual grants that had to be added to that role, kept
in the repo as a record. They are applied out-of-band, e.g.:

```bash
aws iam put-role-policy \
  --role-name github-actions \
  --policy-name cube-mcp-kaniko-deploy \
  --policy-document file://infra/iam/github-actions-kaniko-policy.json
```

## `github-actions-kaniko-policy.json`

Lets the deploy role create/manage the resources added by
`infra/terraform/build.tf` for the remote-image-build feature (see
`docs/remote-build-spec.md`): the kaniko ECR mirror repo, its CloudWatch log
group, the egress-only security group, and the two kaniko IAM roles. Without it,
`terraform apply` stops after creating the S3 context bucket + DynamoDB jobs table
(which the role was already permitted to create).

Notes:
- The ECR resource ARN is `repository/cube-mcp/kaniko*` (no hyphen) so it covers
  both the per-environment repos (`cube-mcp/kaniko-dev`, `cube-mcp/kaniko-prod`)
  and the legacy shared `cube-mcp/kaniko` that dev must delete when migrating to
  the per-env name. A hyphenated `kaniko-*` would deny that transitional delete.
- `ec2:CreateSecurityGroup` authorizes against **two** resources — the
  security-group being created *and* its VPC — so it's pinned to the default VPC
  the AWS-recommended way: two Resource-ARN statements, one on the VPC ARN
  (`vpc-08c13f380d3275af0`) and one on `security-group/*`. There is no statement
  granting create on any other VPC, so the role can only create groups there.
  (The earlier `Condition: ec2:Vpc` form produced `UnauthorizedOperation` — that
  condition-key approach is a documented pitfall for this action; the two-ARN
  form is the reliable pattern.) The manage/delete/describe/tag actions stay
  `Resource: "*"` (a group must already exist to be modified; the create
  constraint is the meaningful boundary).
- `iam:PassRole` here is scoped to the kaniko roles so Terraform can wire the
  task definition; the *runtime* PassRole (cube-cloud → kaniko at RunTask) is a
  separate grant in `build.tf`.
- `KanikoCubeCloudInlinePolicy` grants Put/Get/Delete on inline policies of the
  `cube-mcp-*-ecs-task` role. `build.tf`'s `ecs_task_build` is an inline policy
  attached to that shared cube-cloud role; Terraform needs `DeleteRolePolicy`
  there to tear the build feature back down (removing `build.tf` from a branch
  and applying otherwise fails with `AccessDenied: iam:DeleteRolePolicy` on
  `cube-mcp-<env>-ecs-task:cube-mcp-<env>-ecs-task-build`).
