Repository navigation
Conversation
Every API service's execution role, and the reuploader's role, could read any Secrets Manager secret and any SSM parameter in the account (GetSecretValue on *, GetParameter* on arn:aws:ssm:*), although ECS only uses it to inject the task's task_secrets. The reuploader's is also its task role, so its own code had that access too. The policies are now built in HCL instead of templates: the secret statements grant secretsmanager:GetSecretValue and ssm:GetParameters, the two actions ECS uses to inject secrets, on the ARNs in task_secrets only (every task_secrets value in dev and prod is an SSM parameter or Secrets Manager secret ARN). A task without secrets, like the reuploader, gets no secret statement; its code only uses S3. The other statements are unchanged. Planned with fake inputs as prod's ooniauth (SSM and Secrets Manager secrets), ooniprobe, reverseproxy and the reuploader, from main and from this change: the same resources, task definitions unchanged, and the policies differ only in those statements. terraform validate passes for dev and prod. oonith_service and ooni_dataapi have the same policy but are not used by either environment.
ooniprobe uploads failed reports and reads its private config and the anonymous credentials manifests from S3. Its tasks have no task role, so the AWS SDK falls back to the container host's instance credentials, where those permissions are granted. Every container on the host can get those credentials, and they can't be taken away from the containers while ooniprobe depends on them. ooniapi_service gains an optional task_role_policy: given, the task gets a task role with it (ECS_ENABLE_TASK_IAM_ROLE is already on), whose credentials the SDK prefers over the host's. ooniprobe and ooniprobe_legacy get the S3 policy, now declared once as local.ooniprobe_s3_policy. The instance role keeps the same policy for now, so tasks still running the previous revision keep working during the rollout; the next commit removes it. Planned with fake inputs: only ooniprobe gains a role, its policy and a task_role_arn; the other services are unchanged. The instance role's policy is the same statements as before. terraform validate passes for dev and prod. The other services' code makes no AWS calls of its own, apart from ooniauth's SES calls with its own IAM user's keys and the reuploader, which already has a task role.
The tasks run in bridge mode, so any container could fetch the container host's instance credentials from the metadata service. Those could read every secret in Secrets Manager and ooniprobe's S3 objects, whatever the container's own task was given. - The launch template requires IMDSv2 with a hop limit of 1. The ECS agent (host network) and docker's awslogs driver still reach it; the containers, a hop further on the bridge network, can't. Tasks get AWS credentials from their task role instead, through the ECS agent. - The instance role no longer reads secrets: ECS injects each task's secrets with that task's execution role, and nothing on the host (ecs-setup.sh) reads any. - ooniprobe's S3 policy is removed from the instance role; ooniprobe and ooniprobe_legacy have it as their task role since the previous commit. Planned with fake inputs from main and from this branch: the same cluster resources; only the instance role policy (the two secret statements) and the launch template's metadata_options change. terraform validate passes for dev and prod. Rollout, per environment: 1. Apply the previous commit, and let ooniprobe and ooniprobe_legacy deploy the task definition with the task role (check that failed report uploads and the manifest and config reads keep working). 2. Apply this commit. The autoscaling group launches new hosts from the new template ($Latest) but doesn't refresh running ones on a template change; start an instance refresh, or run aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1 on each running host.
…oken The build roles of ooniapi_service_deployer, ooni_docker_build and oonith_service_deployer had the AWS managed SecretsManagerReadWrite policy. Every buildspec they run (the API services, fastpath, testlists and the reuploader, on master and on the branches dev builds) reads one secret, oonidevops/dockerhub/access_token, to log in to Docker Hub. The roles now get secretsmanager:GetSecretValue on that secret only (its ARN plus the 6 character suffix Secrets Manager adds) instead of the managed policy. The make db-migration targets that read the Postgres URL run on an operator's machine, not in CodeBuild. Planned ooniapi_service_deployer from main and from this change with fake inputs: the same resources, and the build policy differs by that one statement. terraform validate passes for dev and prod.
The pipeline only runs on pushes, so an image whose code doesn't change keeps its base image, and the CA certificates and packages in it, as of its last push. rebuild_schedule, when set, also starts the pipeline on an EventBridge schedule. Off by default, so existing deployers are unchanged.
Forward every path on slack_invite_domains to the slack-invite target group, ahead of the path rules. Nothing changes unless the target group is given.
slackin on ams-slack-1 stopped inviting people: it used Slack's undocumented users.admin.invite and a legacy token, which Slack has been shutting down. ooni/slack-invite replaces it with a form whose requests an admin approves from Slack. It runs as an ooniapi service on the ooniapi cluster, deployed from ooni/slack-invite on every push to main and rebuilt weekly for Debian and ca-certificates updates. Its only secret is the admin channel's incoming webhook, in SSM at /oonidevops/secrets/slack_invite/webhook_url, which must exist before this is applied. slack.ooni.org and slack.ooni.io move from ams-slack-1 to the ooniapi frontend, which forwards every path on them to slack-invite.
As slackin's page did: the workspace's name, and a link to openobservatory.slack.com for people who are already members.
aagbsn
marked this pull request as draft
November 11, 2026 14:58
Terraform Run Output 🤖Format and Style 🖌
|
| Pusher | @aagbsn |
| Action | pull_request |
| Environment | dev |
| Workflow | .github/workflows/check_terraform.yml |
| Last updated | Wed, 11 Nov 2026 15:00:03 GMT |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
prod: run slack-invite on ECS as slack.ooni.org. Based on #507