RFC: App-to-App mTLS via GoRouter

[rkoster]

Summary

This RFC proposes enabling authenticated and authorized app-to-app communication via GoRouter using mutual TLS (mTLS).

View the full RFC

Applications connect to a shared internal domain (apps.mtls.internal), where GoRouter:

• Requires and validates client certificates (Instance Identity)
• Enforces per-route access control using allowed_sources
• Follows a default-deny model (aligned with C2C network policies)

Key Points

• No new infrastructure: Uses existing GoRouter with domain-specific mTLS configuration
• Default-deny security: Routes blocked unless explicitly allowed via allowed_sources
• Internal-only domain: apps.mtls.internal is a separate domain tree, avoiding conflicts with existing apps.internal routes
• Depends on RFC-0027: Route options framework required for allowed_sources support

Implementation Phases

• Phase 1a (mTLS Infrastructure): GoRouter validates client certificates for the mTLS domain
• Phase 1b (Authorization Enforcement): Per-route access control via allowed_sources (co-requisite with 1a)
• Phase 2 (Optional): Egress HTTP proxy on port 8888 for simplified client adoption

cc @cloudfoundry/toc @cloudfoundry/wg-app-runtime-interfaces

[silvestre]

I really like this proposal.

Just to be sure: It would be still possible to have an apps.mtls.internal route allowing access for any source app, so that the authorization check could be done in the app, right?

One use-case would be in the app-autoscaler service, where we expose an mTLS endpoint but check the authorization by determining if the app is bound to an autoscaler service instance, which is dynamic information we could not determine during route creation.

[rkoster]

I really like this proposal.

Just to be sure: It would be still possible to have an apps.mtls.internal route allowing access for any source app, so that the authorization check could be done in the app, right?

One use-case would be in the app-autoscaler service, where we expose an mTLS endpoint but check the authorization by determining if the app is bound to an autoscaler service instance, which is dynamic information we could not determine during route creation.

@silvestre I have update the RFC with:

applications:
- name: autoscaler-api
  routes:
  - route: autoscaler.apps.mtls.internal
    options:
      allowed_sources:
        any: true

[plowin]

Hey @rkoster, I think this proposal is a great enhancement for app developers.

Do you think we could also integrate an operator-switch for people deploying a TLS-terminating reverse-proxy in front of gorouter? This proxy would need to take some parts of the logic, and set the XFCC header. The per-route logic would be similar, but gorouter gets the data from the header instead of the actual TLS handshake.

[rkoster]

Why would you want to use a TLS-terminating reverse-proxy in front of gorouter for app to app traffic? The idea is that bosh dns would point app 2 app traffic directly at the gorouters. Traffic would stay on the private network. How would bosh dns even know about this reverse-proxy? The idea is to make this feature self contained within CF.

[theghost5800]

This idea is really interesting but will be possible to have communication to app containers on different ports or different protocol than http?