coulomb/qonto-assistant
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
qonto-assistant/deploy/k8s/qonto-assistant
History
tegwick 9fbcef7b05 QONTO-WP-0004-T06: draft isolation placement manifests + railiance/app.toml 
Concrete, reviewable placement request per docs/SecurityPractice.md #7
(I1 Reinforced minimum: dedicated node pool/namespace, given internet
reachability via the facade and sole custody of the bank credential).

deploy/k8s/qonto-assistant/: modeled on llm-connect's real deployment
(deploy/k8s/activity-core-llm-connect/) but tightened -- dedicated
namespace (not shared), Deployment starts at replicas:0 (meant to be
scaled 0<->1 by the facade, QONTO-WP-0004-T05), ClusterIP-only Service,
NetworkPolicy default-deny with ingress limited to the facade and
egress limited to DNS+443 (the FQDN-egress limitation is called out
explicitly, not silently widened). Verified: `kubectl kustomize`
renders all six resources cleanly.

externalsecret.yaml depends on CCR-2026-0009 (new), proposed in
railiance-platform: a workload-scoped Kubernetes-auth access lane into
the existing tenants/binky/qonto-api credential, since CCR-2026-0008
is human/OIDC admin access only and unusable by a running pod. Mirrors
CCR-2026-0003's llm-connect/ExternalSecretsOperator pattern. Paired
draft ClusterSecretStore also added there. Both validated against
schemas/credential-change-request.schema.yaml. Status: proposed, not
approved -- explicitly not something this repo can complete alone.

railiance/app.toml: staged-promotion contract (criticality=critical,
mandatory human approval before Stage 2 traffic exposure and Stage 3
promotion, per railiance-cluster/docs/app-toml-contract.md's own rule
for production-critical workloads). Validated against
railiance-cluster/schemas/railiance-app.schema.json.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-24 00:27:37 +02:00
..
configmap.yaml QONTO-WP-0004-T06: draft isolation placement manifests + railiance/app.toml 2026-07-24 00:27:37 +02:00
deployment.yaml QONTO-WP-0004-T06: draft isolation placement manifests + railiance/app.toml 2026-07-24 00:27:37 +02:00
externalsecret.yaml QONTO-WP-0004-T06: draft isolation placement manifests + railiance/app.toml 2026-07-24 00:27:37 +02:00
kustomization.yaml QONTO-WP-0004-T06: draft isolation placement manifests + railiance/app.toml 2026-07-24 00:27:37 +02:00
namespace.yaml QONTO-WP-0004-T06: draft isolation placement manifests + railiance/app.toml 2026-07-24 00:27:37 +02:00
networkpolicy.yaml QONTO-WP-0004-T06: draft isolation placement manifests + railiance/app.toml 2026-07-24 00:27:37 +02:00
README.md QONTO-WP-0004-T06: draft isolation placement manifests + railiance/app.toml 2026-07-24 00:27:37 +02:00
service.yaml QONTO-WP-0004-T06: draft isolation placement manifests + railiance/app.toml 2026-07-24 00:27:37 +02:00

README.md

qonto-assistant Kubernetes manifests (draft)

QONTO-WP-0004-T06. Modeled on llm-connect/deploy/k8s/activity-core-llm-connect/, tightened per docs/SecurityPractice.md §7's isolation-profile request (I1 "Reinforced" minimum, given internet reachability via the facade and sole custody of the bank credential).

Files

File Purpose
namespace.yaml Dedicated qonto-assistant namespace — not shared with activity-core or any other workload
configmap.yaml Non-secret runtime config. Security-integration URLs left unset until key-cape/flex-auth/tenant-engine have confirmed in-cluster addresses
deployment.yaml replicas: 0 by default — meant to be scaled 0↔1 by the facade (T05, not yet built), never run continuously
service.yaml ClusterIP only — never bind the raw port to a public address
networkpolicy.yaml Default-deny; ingress only from the (assumed co-located) facade pod; egress limited to DNS + 443
externalsecret.yaml Syncs API_KEY/API_USER from tenants/binky/qonto-api — depends on CCR-2026-0009 (proposed, not approved)

What is real vs. draft

  • Real, already live: the underlying secret at tenants/binky/qonto-api (CCR-2026-0008, human/OIDC admin access only).
  • Draft, needs approval before applying: externalsecret.yaml and the paired ClusterSecretStore in railiance-platform/argocd/platform-addons/openbao-secretstore/openbao-qonto-assistant.clustersecretstore.yaml both depend on CCR-2026-0009 (workload-scoped Kubernetes-auth access lane), which is status: proposed — not yet approved by platform-operator/binky-tenant-owner.
  • Open question, not decided here: whether the facade (QONTO-WP-0004-T05) lands in this same namespace (assumed by networkpolicy.yaml's ingress rule) or a separate one. Update the podSelector/namespaceSelector in networkpolicy.yaml once that's decided.
  • Known egress-policy limitation: native Kubernetes NetworkPolicy has no FQDN-aware egress rule, so the 0.0.0.0/0:443 egress rule is broader than the intent (only thirdparty.qonto.com and bao.coulomb.social). Called out in networkpolicy.yaml's own comment rather than silently widened further.

Applying (once CCR-2026-0009 is approved)

kubectl kustomize deploy/k8s/qonto-assistant   # render and review first
kubectl apply -k deploy/k8s/qonto-assistant
kubectl -n qonto-assistant scale deployment/qonto-assistant --replicas=1  # manual wake, until T05 exists

See railiance/app.toml for the staged-promotion contract (Stage 1 local → Stage 2 canary → Stage 3 production) this deployment should go through, per railiance-cluster/docs/app-toml-contract.md.