hackforla / hackforla/incubator

Epic: Scope machine-to-machine IAM permissions to projects using the project tag

Open
#206 0 comments 0 reactions 0 assignees View on GitHub
complexity: large epic feature: IAM role: DevOps Engineer size: 13+pt
Dominant language
HCL
Stars
6
Forks
18
Avg merge
1h 9m
Merged PRs (30d)
42

Description

### Overview

We need incubator to generate a CI/CD role per project, and an ECS execution role and an ECS task role for each container, whose permissions are granted only against resources tagged with that project's `project` tag. Today two of those three roles share permissions across every project, and the `project` tag is not consistent enough to authorize against.

### Action Items

Tracked as sub-issues. This issue closes when they do.

### Resources/Instructions

The permission matrix this epic implements:

| Role | Project-scoped grant |
|---|---|
| CI/CD role | ECR, ECS |
| ECS execution role | ECR (image pull), Secrets (SSM parameters) |
| ECS task role | S3, Cognito |

Each role additionally keeps whatever it needs to function at all — the execution role writes logs, the task role has ECS Exec. Note the execution role's ECR access is a **project-scoped grant in its own right**, not incidental: it pulls the container image, and it should be able to pull only its own project's images, in the same way the CI/CD role should be able to push only its own project's images.

The three identities and where they are defined:

1. **CI/CD role** — `terraform/modules/cicd_integration/main.tf`. Already one per project, and its trust policy is already scoped to that project's repository. Its *permissions* are not: all four roles attach the single shared policy `incubator_builder`, which grants ECR push to every repository and `ecs:UpdateService` on every service in the cluster.
2. **ECS task role** — `aws_iam_role.instance` in `terraform/modules/container/main.tf`. Already one per container.
3. **ECS execution role** — a hardcoded ARN in `terraform/modules/container/main.tf`, one role shared by all ten containers, carrying `AmazonSSMFullAccess`. This is the largest gap against the design and the widest permission in the account. It becomes one role per container, generated by the module alongside the task role.

How the project value reaches a policy: policies name the project **literally**, interpolated by Terraform, rather than self-referencing `${aws:PrincipalTag/project}`. The `project` tag on the roles themselves is for inventory and reporting, not authorization.

**Sequencing matters.** Tag-based access control fails closed, so a policy conditioned on a tag that is missing or wrong denies access rather than over-granting. The tag-correctness issues must land and be verified before any policy issue does.

**Naming trap:** the shared execution role is named `incubator-prod-ecs-task-role` while the actual task roles are named `ecs-container-*`. The names are inverted relative to their function.

Dependency: hackforla/incubator#184 brings the shared execution role under Terraform.

Contributor guide

Open the contributing guide

Research direction

Start by reading terraform/modules/cicd_integration/main.tf and terraform/modules/container/main.tf, then review the tag-correctness work and dependency hackforla/incubator#184. The epic is done when its sub-issues implement the stated project-scoped permission matrix, including separate ECS execution roles, without relying on missing or incorrect project tags.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, terraform
Domain
authorization, cloud, infrastructure, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.