feat(registry): add authentication and ECS deployment support

[toadkicker]

Summary

Implemented comprehensive authentication and deployment infrastructure for the PAP registry:

• Bearer token authentication with constant-time comparison
• Optional OIDC and API key management (scaffolded)
• Terraform IaC for ECS deployment in baursoftware-infra
• Complete end-to-end testing and integration tests

Changes

Core Implementation (Tasks 1-4):

• ✅ Pluggable auth module with Bearer token validator
• ✅ Extended Config with OIDC, API keys, auth settings
• ✅ Auth middleware integrated into Axum router
• ✅ Optional OIDC + AWS SDK dependencies

UI & Deployment (Tasks 5-7):

• ✅ Settings page UI for auth status and API key management
• ✅ Docker Compose updated with auth environment variables
• ✅ Terraform module for ECS deployment (variables.tf, secrets.tf, main.tf, outputs.tf, README.md)

Testing & Documentation (Tasks 8-11):

• ✅ Operator & agent integration documentation
• ✅ Docker image built and pushed to ECR (332745743295.dkr.ecr.us-east-1.amazonaws.com/pap-registry:latest)
• ✅ End-to-end authentication testing (all passed)
• ✅ Integration tests for auth middleware (4 tests, all passing)

Test Plan

• All 210 existing tests pass
• 4 new integration tests for Bearer token validation
• End-to-end authentication flow verified locally
• Docker image builds and pushes to ECR
• Terraform module validates without errors
• Documentation complete for operators and agents

Deployment

The registry can now be deployed to baursoftware-infra ECS cluster:

1. Copy terraform/registry/terraform.tfvars.example to terraform.tfvars
2. Provide baursoftware-infra infrastructure references (VPC, ECS cluster, ALB)
3. Run terraform apply

Token is stored securely in AWS Secrets Manager and injected at runtime.

Breaking Changes

None. Federation endpoints remain unauthenticated. Admin API routes require Bearer token when configured.

🤖 Generated with Claude Code

[gitguardian]

️✅ There are no secrets present in this pull request anymore.

If these secrets were true positive and are still valid, we highly recommend you to revoke them.
While these secrets were previously flagged, we no longer have a reference to the
specific commits where they were detected. Once a secret has been leaked into a git
repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.

---

^{_{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}}

[greptile-apps]

Greptile Summary

This PR adds Bearer token authentication to the PAP registry admin routes, introduces a Terraform module for ECS deployment with Secrets Manager integration, and scaffolds OIDC/API-key support. The auth logic itself is sound — constant-time comparison is implemented correctly — but several infrastructure and secrets-hygiene issues need to be addressed before merge.

• Committed .env with a real token value: apps/registry/.env is tracked in git and contains an actual PAP_REGISTRY_ADMIN_TOKEN value; it should be .gitignored or its token line commented out like .env.example.
• Terraform admin_token_secret has a weak default: if no tfvars file overrides the variable, Terraform silently provisions Secrets Manager with a known placeholder string, defeating the sensitive = true marking.
• ECS health check uses plain HTTP while TLS is on by default: the health check command uses http:// rather than https://, meaning every ECS task will fail its health check and the service will never become stable.
• Real AWS account IDs and resource IDs in the example tfvars: terraform.tfvars.example contains a real account number, VPC ID, and cluster ARN that expose production topology.

Confidence Score: 3/5

Not safe to merge as-is: the committed .env file with a real token and the Terraform default credential are active security concerns, and the HTTP health check will prevent the ECS service from ever reaching a healthy state.

The core auth logic (constant-time comparison, middleware wiring, state integration) is well-implemented. However, the .env file commits a real credential to version control, the Terraform variable for the admin token silently falls back to a known-weak placeholder, the example tfvars file exposes real production AWS identifiers, and the ECS health check targets plain HTTP while the server uses TLS by default.

apps/registry/.env (committed token), terraform/registry/variables.tf (weak default), terraform/registry/main.tf (HTTP health check), terraform/registry/terraform.tfvars.example (real AWS IDs)

Security Review

• Credential in version control (apps/registry/.env): a real admin Bearer token is committed in a tracked file; any repository reader can use it against deployments that copy the file without modification.
• Weak Terraform secret default (terraform/registry/variables.tf): admin_token_secret defaults to a hardcoded placeholder string; a terraform apply without an overriding tfvars provisions infrastructure with a publicly-known credential.
• Infrastructure enumeration (terraform/registry/terraform.tfvars.example): real AWS account ID, VPC ID, and ECS cluster ARN are present in the committed example file, exposing the account topology to anyone with repository access.

Important Files Changed

Filename	Overview
apps/registry/.env	Committed .env file contains an actual admin token value that should not be in version control; should be gitignored or follow the .env.example commented-out pattern.
apps/registry/src/auth/bearer.rs	New bearer token validator using constant-time comparison; correct implementation with good unit test coverage.
apps/registry/src/main.rs	Auth middleware wired into admin router; the Bearer prefix check occurs outside the constant-time comparator, which is a minor timing-side-channel concern worth addressing.
apps/registry/src/state.rs	Cleanly adds bearer_validator to AppState, initialized from config at startup.
apps/registry/src/config.rs	Adds OIDC issuer/audience, AWS region, and API key enable flag to Config struct with correct env-var parsing.
apps/registry/tests/auth_integration_test.rs	Integration tests cover happy path, rejection, and disabled-mode cases, but largely duplicate unit tests in bearer.rs rather than testing the middleware end-to-end via HTTP.
terraform/registry/variables.tf	Sensitive admin_token_secret variable has a weak hardcoded default that will be silently used if not overridden, enabling an insecure deployment.
terraform/registry/main.tf	ECS health check uses plain HTTP while the service defaults to TLS, which will cause the container to be marked unhealthy; ECR pull permissions are also broader than necessary.
terraform/registry/secrets.tf	Correctly provisions a Secrets Manager secret and version for the admin token; will be populated from the problematic variable default if not overridden.
terraform/registry/terraform.tfvars.example	Contains real AWS account IDs, VPC IDs, and cluster ARNs that expose production infrastructure topology; should use placeholder values.

Sequence Diagram

sequenceDiagram
    participant Client
    participant Middleware as Auth Middleware (main.rs)
    participant Validator as BearerTokenValidator
    participant AdminRouter as Admin Routes

    Client->>Middleware: HTTP request + Authorization header
    Middleware->>Middleware: Extract Bearer prefix
    alt Token configured (admin_token.is_some())
        Middleware->>Validator: validate(Some(token))
        alt Token matches (constant_time_eq)
            Validator-->>Middleware: true
            Middleware->>AdminRouter: next.run(req)
            AdminRouter-->>Client: 200 OK
        else Token mismatch or missing
            Validator-->>Middleware: false
            Middleware-->>Client: 401 Unauthorized
        end
    else No token configured
        Middleware->>AdminRouter: pass-through (no auth layer)
        AdminRouter-->>Client: 200 OK
    end

Loading

Comments Outside Diff (4)

1. terraform/registry/main.tf, line 1001-1007 (link)

   Health Check Protocol Mismatch (HTTP vs HTTPS)

   The ECS container health check calls http://localhost:${var.port}/federation/identity, but the server enables TLS by default (PAP_REGISTRY_NO_TLS is not set in the task environment). In TLS mode curl -f http://… will receive a TLS handshake response to a plain-HTTP request and return a non-zero exit code, so the container will cycle through startPeriod and eventually be marked unhealthy. The Docker Compose health check correctly uses https://… with -k; the Terraform version should do the same: curl -fk https://localhost:${var.port}/federation/identity || exit 1.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: terraform/registry/main.tf
   Line: 1001-1007
   
   Comment:
   **Health Check Protocol Mismatch (HTTP vs HTTPS)**
   
   The ECS container health check calls `http://localhost:${var.port}/federation/identity`, but the server enables TLS by default (`PAP_REGISTRY_NO_TLS` is not set in the task environment). In TLS mode `curl -f http://…` will receive a TLS handshake response to a plain-HTTP request and return a non-zero exit code, so the container will cycle through `startPeriod` and eventually be marked unhealthy. The Docker Compose health check correctly uses `https://…` with `-k`; the Terraform version should do the same: `curl -fk https://localhost:${var.port}/federation/identity || exit 1`.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

2. terraform/registry/main.tf, line 893-924 (link)

   Overly Broad ECR Permissions

   ecr:BatchGetImage and ecr:GetDownloadUrlForLayer are granted with Resource = "*", giving the task execution role access to pull any image in the account. These two actions can be scoped to the specific ECR repository ARN. Only ecr:GetAuthorizationToken actually requires Resource = "*" because it operates at the registry level, not the repository level.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: terraform/registry/main.tf
   Line: 893-924
   
   Comment:
   **Overly Broad ECR Permissions**
   
   `ecr:BatchGetImage` and `ecr:GetDownloadUrlForLayer` are granted with `Resource = "*"`, giving the task execution role access to pull any image in the account. These two actions can be scoped to the specific ECR repository ARN. Only `ecr:GetAuthorizationToken` actually requires `Resource = "*"` because it operates at the registry level, not the repository level.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

3. apps/registry/src/main.rs, line 434-460 (link)

   Middleware Auth Check Bypassed on Bearer Prefix Mismatch

   The inline middleware only validates the token if the header value starts with exactly "Bearer " (with a trailing space). The Bearer prefix check happens before the constant-time comparison — meaning the response time for a malformed scheme is detectably different from a correct scheme with a wrong token. Consider factoring this logic into a method on BearerTokenValidator or extractor.rs where it can be tested directly.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/registry/src/main.rs
   Line: 434-460
   
   Comment:
   **Middleware Auth Check Bypassed on `Bearer ` Prefix Mismatch**
   
   The inline middleware only validates the token if the header value starts with exactly `"Bearer "` (with a trailing space). The `Bearer` prefix check happens *before* the constant-time comparison — meaning the response time for a malformed scheme is detectably different from a correct scheme with a wrong token. Consider factoring this logic into a method on `BearerTokenValidator` or `extractor.rs` where it can be tested directly.
   
   How can I resolve this? If you propose a fix, please make it concise.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

   

4. terraform/registry/variables.tf, line 1185-1190 (link)

   Insecure Default for Sensitive Auth Variable

   admin_token_secret is marked sensitive = true but still carries a hardcoded placeholder string as its default. Terraform will silently use that placeholder if no tfvars file overrides it — meaning the ECS task can start with authentication enabled and a publicly-known weak credential. Removing the default block entirely forces operators to supply a real value and prevents an accidental insecure deployment.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: terraform/registry/variables.tf
   Line: 1185-1190
   
   Comment:
   **Insecure Default for Sensitive Auth Variable**
   
   `admin_token_secret` is marked `sensitive = true` but still carries a hardcoded placeholder string as its `default`. Terraform will silently use that placeholder if no `tfvars` file overrides it — meaning the ECS task can start with authentication enabled and a publicly-known weak credential. Removing the `default` block entirely forces operators to supply a real value and prevents an accidental insecure deployment.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

Prompt To Fix All With AI

Fix the following 6 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 6
terraform/registry/main.tf:1001-1007
**Health Check Protocol Mismatch (HTTP vs HTTPS)**

The ECS container health check calls `http://localhost:${var.port}/federation/identity`, but the server enables TLS by default (`PAP_REGISTRY_NO_TLS` is not set in the task environment). In TLS mode `curl -f http://…` will receive a TLS handshake response to a plain-HTTP request and return a non-zero exit code, so the container will cycle through `startPeriod` and eventually be marked unhealthy. The Docker Compose health check correctly uses `https://…` with `-k`; the Terraform version should do the same: `curl -fk https://localhost:${var.port}/federation/identity || exit 1`.

### Issue 2 of 6
terraform/registry/terraform.tfvars.example:19-23
**Real AWS Infrastructure IDs in Example File**

This example file contains real AWS resource identifiers — account ID `332745743295`, VPC ID `vpc-05838cd61af99ae79`, and a concrete ECS cluster ARN. Committing these to a public (or even internal-only) repository exposes the account topology. Prefer generic placeholders like `"vpc-REPLACE_ME"` or `"arn:aws:ecs:us-east-1:ACCOUNT_ID:cluster/CLUSTER_NAME"` in example files.

### Issue 3 of 6
terraform/registry/main.tf:893-924
**Overly Broad ECR Permissions**

`ecr:BatchGetImage` and `ecr:GetDownloadUrlForLayer` are granted with `Resource = "*"`, giving the task execution role access to pull any image in the account. These two actions can be scoped to the specific ECR repository ARN. Only `ecr:GetAuthorizationToken` actually requires `Resource = "*"` because it operates at the registry level, not the repository level.

### Issue 4 of 6
apps/registry/src/main.rs:434-460
**Middleware Auth Check Bypassed on `Bearer ` Prefix Mismatch**

The inline middleware only validates the token if the header value starts with exactly `"Bearer "` (with a trailing space). The `Bearer` prefix check happens *before* the constant-time comparison — meaning the response time for a malformed scheme is detectably different from a correct scheme with a wrong token. Consider factoring this logic into a method on `BearerTokenValidator` or `extractor.rs` where it can be tested directly.

### Issue 5 of 6
apps/registry/.env:30
**Credential Committed to Git**

`apps/registry/.env` is a committed file (not `.gitignore`d) containing an actual token value for `PAP_REGISTRY_ADMIN_TOKEN`. Even labeled as a "test" token, any value committed here becomes a known-credential risk — if this file is copied to a production host without modification, the admin API is immediately accessible by anyone who has read the repository. The `.env.example` file correctly comments the variable out; the `.env` file should either be added to `.gitignore` or match that same commented-out pattern.

### Issue 6 of 6
terraform/registry/variables.tf:1185-1190
**Insecure Default for Sensitive Auth Variable**

`admin_token_secret` is marked `sensitive = true` but still carries a hardcoded placeholder string as its `default`. Terraform will silently use that placeholder if no `tfvars` file overrides it — meaning the ECS task can start with authentication enabled and a publicly-known weak credential. Removing the `default` block entirely forces operators to supply a real value and prevents an accidental insecure deployment.

_{Reviews (1): Last reviewed commit: "test(registry-auth): add integration tes..." | Re-trigger Greptile}

[greptile-apps]

Real AWS Infrastructure IDs in Example File

This example file contains real AWS resource identifiers — account ID 332745743295, VPC ID vpc-05838cd61af99ae79, and a concrete ECS cluster ARN. Committing these to a public (or even internal-only) repository exposes the account topology. Prefer generic placeholders like "vpc-REPLACE_ME" or "arn:aws:ecs:us-east-1:ACCOUNT_ID:cluster/CLUSTER_NAME" in example files.

Prompt To Fix With AI

This is a comment left during a code review.
Path: terraform/registry/terraform.tfvars.example
Line: 19-23

Comment:
**Real AWS Infrastructure IDs in Example File**

This example file contains real AWS resource identifiers — account ID `332745743295`, VPC ID `vpc-05838cd61af99ae79`, and a concrete ECS cluster ARN. Committing these to a public (or even internal-only) repository exposes the account topology. Prefer generic placeholders like `"vpc-REPLACE_ME"` or `"arn:aws:ecs:us-east-1:ACCOUNT_ID:cluster/CLUSTER_NAME"` in example files.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Credential Committed to Git

apps/registry/.env is a committed file (not .gitignored) containing an actual token value for PAP_REGISTRY_ADMIN_TOKEN. Even labeled as a "test" token, any value committed here becomes a known-credential risk — if this file is copied to a production host without modification, the admin API is immediately accessible by anyone who has read the repository. The .env.example file correctly comments the variable out; the .env file should either be added to .gitignore or match that same commented-out pattern.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/registry/.env
Line: 30

Comment:
**Credential Committed to Git**

`apps/registry/.env` is a committed file (not `.gitignore`d) containing an actual token value for `PAP_REGISTRY_ADMIN_TOKEN`. Even labeled as a "test" token, any value committed here becomes a known-credential risk — if this file is copied to a production host without modification, the admin API is immediately accessible by anyone who has read the repository. The `.env.example` file correctly comments the variable out; the `.env` file should either be added to `.gitignore` or match that same commented-out pattern.

How can I resolve this? If you propose a fix, please make it concise.