Skip to content

feat(connectivity): protect connectivity-api with the stack auth issuer - #522

Draft
Dav-14 wants to merge 2 commits into
fix/gatewayhttpapi-skip-dead-default-servicefrom
feat/connectivity-api-auth
Draft

feat(connectivity): protect connectivity-api with the stack auth issuer#522
Dav-14 wants to merge 2 commits into
fix/gatewayhttpapi-skip-dead-default-servicefrom
feat/connectivity-api-auth

Conversation

@Dav-14

@Dav-14 Dav-14 commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

Problem

The connectivity-api companion is exposed through the stack gateway at /api/connectivity, but nothing wires its OIDC protection: the module reconciler never sets spec.api.auth on the delegated connectivity.formance.com/Connectivity, so the connectivity operator renders the API pod with AUTH_ENABLED=false. The gateway does not enforce auth per route either (the Secured rule flag is not rendered in the Caddyfile), so on a stack with an Auth module — where ledger and payments self-verify bearer tokens — connectivity-api is the only module API reachable without a token.

Fix

connectivities.Reconcile now resolves the module's protection through the shared auths.GetProtectedConfiguration (the same machinery behind ledger/payments AUTH_ENABLED/AUTH_ISSUER):

  • stack has an Auth module → spec.api.auth.issuer is set to the stack auth issuer and spec.api.auth.checkScopes follows the auth.connectivity.check-scopes Setting (platform default: false);
  • no Auth module → spec.api.auth is removed and the API keeps running unauthenticated (behind-VPN / in-cluster deployments);
  • resolution failure → hard error with an APIAuthResolveFailed condition.

checkScopes is always set explicitly because the connectivity CRD defaults it to true while the platform convention defaults to false. The connectivity CRD models a single trusted issuer, so additional auth.issuers Settings entries are not propagated.

Also adds docs/04-Modules/12-Connectivity.md (the module had no page), covering the module basics and the auth behavior.

Tests

  • internal/resources/connectivities/init_test.go:
    • issuer + explicit checkScopes: false wired when the stack has an Auth module (written first, watched fail);
    • checkScopes: true when the auth.connectivity.check-scopes Setting is enabled (written first, watched fail);
    • stale spec.api.auth cleared when the stack has no Auth module (written first, watched fail);
    • hard error + APIAuthResolveFailed condition when the Auth lookup fails (interceptor, added for error-branch coverage).
  • Package suite green, coverage 72.1% (baseline 71.9%).
  • just pre-commit (tidy, lint, generate, manifests, helm validate, docs, settings catalog) — no generated drift.

Stack created with GitHub Stacks CLIGive Feedback 💬

When the stack has an Auth module, wire spec.api.auth on the delegated
Connectivity resource through auths.GetProtectedConfiguration, mirroring
how ledger and payments self-verify bearer tokens: issuer from the stack
auth URL, scope checking driven by the auth.connectivity.check-scopes
Setting. Without an Auth module the api.auth block is cleared and the
API keeps running unauthenticated.
@coderabbitai

coderabbitai Bot commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 1847ce9e-0715-4336-ba36-6bfdc70c7206

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@Dav-14 Dav-14 changed the title feat/connectivity api auth feat(connectivity): protect connectivity-api with the stack auth issuer Aug 14, 2026
…yments

The connectivity module delegates its workloads to a
connectivity.formance.com Connectivity resource, so the applications
package's withJsonLogging mutator — which sets JSON_FORMATTING_LOGGER on
Deployments the operator owns — never reaches them. Wire the same
platform-wide logging.json Setting through spec.monitoring.logs.format on
the delegated resource instead: the connectivity operator turns that field
into JSON_FORMATTING_LOGGER on the core, connectivity-api and connector
workloads.

The format is independent of telemetry export, so the monitoring block is
now emitted for json logging alone (carrying no enabled signal) and pruned
only once both telemetry and json logging are off. Only "json" is
forwarded; the CRD already defaults the field to "text".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

1 participant