feat: multi-org github app routing with yaml config

[lee2sh]

Multi-Org GitHub App Routing

Problem

octo-sts supports multiple GitHub Apps, but only as a flat pool for rate-limit scaling — all apps serve all orgs indiscriminately. There's no way to:

• Assign dedicated apps to specific GitHub organizations
• Use different credential types per app (e.g., KMS for org-A, injected PEM for org-B)
• Get a clear error when a request arrives for an org with no configured apps

The env-var config (GITHUB_APP_IDS, KMS_KEYS) is structurally limited to a single credential type across all apps.

Solution

Introduce a YAML config file (pointed to by APP_CONFIG_FILE) that maps orgs to their dedicated app pools, each with per-app credential configuration:

orgs:
  - name: org-a
    apps:
      - app_id: 111
        kms_key: projects/.../cryptoKeyVersions/1
  - name: org-b
    apps:
      - app_id: 222
        private_key: "${INJECTED_PEM}"  # env var expanded at load time

Let me know what you guys think!

[joedborg]

Hi @lee2sh, thanks for the PR. I like this approach. Just to confirm, if you have a setup like us, we would do something like

orgs:
  - name: "*"
    apps:
      - app_id: 111
        kms_key: projects/.../cryptoKeyVersions/1
      - app_id: 112
        kms_key: projects/.../cryptoKeyVersions/2
      - app_id: 113
        kms_key: projects/.../cryptoKeyVersions/3

...etc?

[lee2sh]

Hi @lee2sh, thanks for the PR. I like this approach. Just to confirm, if you have a setup like us, we would do something like

orgs:
  - name: "*"
    apps:
      - app_id: 111
        kms_key: projects/.../cryptoKeyVersions/1
      - app_id: 112
        kms_key: projects/.../cryptoKeyVersions/2
      - app_id: 113
        kms_key: projects/.../cryptoKeyVersions/3

...etc?

hi @joedborg, thanks for taking a look! I really appreciate your feedback.

Yes, that config does exactly what you'd expect. The router stores {"*": <pool with apps 111/112/113>}, and it will fall back to that wildcard pool. Inside the pool, the 3 apps are load-balanced based on the current implementation.

Let me know if you have any more questions!

[jmeridth]

🤖 AI-assisted review.

Thanks @lee2sh -- nice approach. Wrapping the existing round-robin + quota managers into per-org OrgPools with a * wildcard fallback means no-config deployments behave exactly as they do today, which is the right call.

It's conflicting with main now -- could you rebase? Heads-up that it reworks the NewSecurityTokenServiceServer signature and the cmd/app wiring, which a couple of other in-flight PRs also touch (#1283, #1141), so you may hit some follow-on conflicts depending on merge order.

Happy to do a full review once it's rebased. Thanks for the contribution!

[lee2sh]

🤖 AI-assisted review.

Thanks @lee2sh -- nice approach. Wrapping the existing round-robin + quota managers into per-org OrgPools with a * wildcard fallback means no-config deployments behave exactly as they do today, which is the right call.

It's conflicting with main now -- could you rebase? Heads-up that it reworks the NewSecurityTokenServiceServer signature and the cmd/app wiring, which a couple of other in-flight PRs also touch (#1283, #1141), so you may hit some follow-on conflicts depending on merge order.

Happy to do a full review once it's rebased. Thanks for the contribution!

Hello @jmeridth, thank you for your review! I'm currently travelling but will rebase as soon as I get decent internet.