Skip to content

Commit bd54385

Browse files
mreuvekampmreuvekamp
authored
Merge branch 'main' into feature/784-notificatie-via-fsc
2 parents dd061fd + 48399c0 commit bd54385

15 files changed

Lines changed: 754 additions & 27 deletions

File tree

‎demo/environment/logius/deploy/local/docker-compose.yaml‎

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -206,6 +206,19 @@ services:
206206
TLS_GROUP_ROOT_CERT: /pki/ca/root.pem
207207
TLS_GROUP_CERT: /pki/out/logius/outway/cert.pem
208208
TLS_GROUP_KEY: /pki/out/logius/outway/key.pem
209+
# TLS op de serve-poort waar de afnemende app binnenkomt. Op ZAD staat dit aan (zie
210+
# deploy/zad/upsert-peer.sh): de app weigert daar een http-endpoint. Lokaal default uit,
211+
# want de harness draait in dev/test — waar die eis niet geldt — en de smokes bellen de
212+
# outway over http, op 8443 in de federatie-overlay en op 58443 in de hostnet-overlay.
213+
#
214+
# OUTWAY_LISTEN_HTTPS=true speelt het ZAD-pad na, met pki/internal/logius/ca/root.pem als
215+
# anker. Bel 'm dan op de naam outway.logius.fsc-test.local en niet op zijn IP: het interne
216+
# cert draagt alleen DNS-SANs (pki/gen-csr.sh), dus een IP faalt op hostnaam-verificatie.
217+
# Onder de overlays luistert hij op een IP, dus daar hoort een --resolve of een extra_hosts
218+
# bij; de smokes zelf zijn hier niet op ingericht.
219+
LISTEN_HTTPS: "${OUTWAY_LISTEN_HTTPS:-false}"
220+
TLS_SERVER_CERT: /pki/internal/logius/outway/cert.pem
221+
TLS_SERVER_KEY: /pki/internal/logius/outway/key.pem
209222
volumes:
210223
- "${PKI_DIR:?zet PKI_DIR in .env}:/pki:ro"
211224
networks:

‎demo/environment/logius/deploy/zad/cert-manifest.md‎

Lines changed: 17 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -76,8 +76,23 @@ de eigen manager op de internal-PKI) — vandaar geen `out/logius/controller/*`-
7676
| `out/logius/outway/cert.pem` | `out/logius/outway/cert.pem` | `TLS_GROUP_CERT` |
7777
| `out/logius/outway/key.pem` | `out/logius/outway/key.pem` | `TLS_GROUP_KEY` |
7878
| `internal/logius/ca/root.pem` | `internal/logius/ca/root.pem` | `TLS_ROOT_CERT` |
79-
| `internal/logius/outway/cert.pem` | `internal/logius/outway/cert.pem` | `TLS_CERT` |
80-
| `internal/logius/outway/key.pem` | `internal/logius/outway/key.pem` | `TLS_KEY` |
79+
| `internal/logius/outway/cert.pem` | `internal/logius/outway/cert.pem` | `TLS_CERT`, `TLS_SERVER_CERT` |
80+
| `internal/logius/outway/key.pem` | `internal/logius/outway/key.pem` | `TLS_KEY`, `TLS_SERVER_KEY` |
81+
82+
Het interne cert-paar draagt twee rollen op de outway: als client richting manager, controller en
83+
txlog (`TLS_CERT`/`TLS_KEY`), en als server-cert op de serve-poort `:8443` waar `berichtenuitvraag`
84+
binnenkomt (`TLS_SERVER_CERT`/`TLS_SERVER_KEY`, actief door `LISTEN_HTTPS=true`). Geen extra
85+
bijlage nodig: het is hetzelfde bestand, en de Service-namen staan al als SAN in het cert.
86+
87+
De afnemende kant heeft datzelfde CA-anker nodig. Op het `uitvraag`-component (deployment `test`)
88+
is dat een bijlage met dezelfde bron en hetzelfde pad als hierboven:
89+
90+
| Bijlage-pad (`/etc/fsc/...`) | Bronbestand (`pki/...`) | Env-var op uitvraag |
91+
|-------------------------------|-------------------------------------------|--------------------|
92+
| `internal/logius/ca/root.pem` | `internal/logius/ca/root.pem` | `QUARKUS_TLS_OUTWAY_TRUST_STORE_PEM_CERTS` (absoluut: `/etc/fsc/internal/logius/ca/root.pem`) |
93+
94+
De bijlage-id's zelf staan niet in dit document — `zadctl attachment list` is daarvoor de bron van
95+
waarheid. Zie verder `docs/operator-handleiding-uitvraag.md` en `cutover-interne-outway.md`.
8196

8297
## logius-fscinway (inway)
8398

‎demo/environment/logius/deploy/zad/cutover-interne-outway.md‎

Lines changed: 188 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,188 @@
1+
# Cutover — uitvraag naar de cluster-interne outway
2+
3+
> Draaiboek voor het omzetten van `berichtenuitvraag` van de publieke ingress-URL van de outway
4+
> naar zijn cluster-interne Service-adres. Hoort bij de wijziging die `LISTEN_HTTPS` op
5+
> `logius-fscoutway` zet; achtergrond in `docs/plans/2026-08-19-outway-https-clusterip.md`.
6+
7+
Doeladres:
8+
9+
```
10+
https://fsc-logius-logius-fscoutway.rig-prd-mpfb-8wh.svc.cluster.local:8443
11+
```
12+
13+
De Service heet `<deployment>-<component>` en leeft in namespace `rig-prd-<project>`. Let op dat
14+
`zadctl deployment describe` `mpfb-8wh` als "Namespace" toont; dat is het project-id.
15+
16+
## Dit is een cutover, geen toevoeging
17+
18+
Twee dingen maken dat de stappen in één venster horen en niet los uitgerold kunnen worden.
19+
20+
**De bestaande ingress-route breekt zodra de outway TLS spreekt.** De gerenderde Ingress
21+
(`logius-fscoutway-ingress.yaml`) termineert TLS aan de rand (`tls: - {}`) en praat plain HTTP
22+
naar poort 8443; er staat geen `backend-protocol: HTTPS`-annotatie op. Zet je `LISTEN_HTTPS=true`,
23+
dan spreekt de pod TLS en levert de publieke route 502.
24+
25+
**Het trust-anker vervangt de JVM-default trust-store, het vult die niet aan.** Zodra
26+
`quarkus.tls.outway` bestaat valideert élk magazijn-endpoint tegen de interne CA — ook een
27+
endpoint dat nog op de publieke ingress staat, met een publiek certificaat. Vandaar dat het anker
28+
per deployment gaat zolang niet elke deployment mee is.
29+
30+
## Voorwaarden
31+
32+
- `ZAD_API_KEY` voor project `mpfb-8wh` staat in de omgeving (`.env.zadctl`); `zadctl deployment
33+
list` werkt.
34+
- De wijziging is uitgerold, zodat de app de TLS-configuratie kent.
35+
36+
## Stap 0 — netwerktoegang tussen de twee deployments
37+
38+
Deployments van hetzelfde project mogen elkaar standaard niet bereiken. De platform-service
39+
`cross-domain-access` heft dat gericht op, en vraagt **twee** regels: een `outbound` bij de
40+
bellende kant en een `inbound` bij de gebelde kant. Eén van de twee is niet genoeg — de ontvanger
41+
geeft de toestemming.
42+
43+
`zadctl service config set` schrijft het hele document; een veld dat je niet noemt wordt
44+
verwijderd. Lees dus eerst wat er staat (`zadctl --json service config get cross-domain-access`)
45+
en stuur het complete beeld terug:
46+
47+
```yaml
48+
# cross-domain-access.yaml
49+
inbound:
50+
- name: uitvraag-naar-logius-fscoutway
51+
from: { project: mpfb-8wh, deployment: test, component: uitvraag }
52+
to: { component: logius-fscoutway, port: 8443 }
53+
outbound:
54+
- name: uitvraag-naar-logius-fscoutway
55+
from: { component: uitvraag }
56+
to: { project: mpfb-8wh, deployment: fsc-logius, component: logius-fscoutway, port: 8443 }
57+
```
58+
59+
```bash
60+
zadctl service config set cross-domain-access --target project -f cross-domain-access.yaml --dry-run
61+
zadctl service config set cross-domain-access --target project -f cross-domain-access.yaml
62+
```
63+
64+
**`from.deployment` op de inbound-regel is niet optioneel in de praktijk.** Het schema zegt dat je
65+
'm open mag laten, en de API accepteert dat ook — maar er verschijnt dan géén NetworkPolicy voor
66+
de ontvangende kant, zonder waarschuwing. Logisch achteraf: de renderer bouwt een `podSelector`
67+
op het label `app: <deployment>-<component>`, en zonder deployment valt dat label niet te maken.
68+
Elke bellende deployment heeft dus zijn eigen inbound-regel nodig; PR-previews die ook op de
69+
interne route moeten, komen er los bij.
70+
71+
Controleer de uitkomst aan de gerenderde manifests, niet aan de API-respons: onder
72+
`rig-cluster-application-test/odcn-production/mpfb-8wh/` horen nu
73+
`test/test-cross-domain-access-uitvraag-network-policy.yaml` (Egress) én
74+
`fsc-logius/fsc-logius-cross-domain-access-logius-fscoutway-network-policy.yaml` (Ingress) te
75+
staan, elkaars spiegelbeeld op poort 8443.
76+
77+
## Stappen
78+
79+
**1. De outway laat TLS toe op zijn serve-poort.**
80+
81+
Niet via `upsert-peer.sh apply`: ZAD past `env_vars` uit een component-body alleen toe bij
82+
component-*creatie*, dus een re-POST verandert niets. De user-env-laag werkt wel op een bestaande
83+
component:
84+
85+
```bash
86+
zadctl env add -c logius-fscoutway \
87+
LISTEN_HTTPS=true \
88+
TLS_SERVER_CERT=/etc/fsc/internal/logius/outway/cert.pem \
89+
TLS_SERVER_KEY=/etc/fsc/internal/logius/outway/key.pem
90+
```
91+
92+
Beide certificaat-paden zijn de bijlagen die er al hangen (`cert-manifest.md`); er hoeft niets
93+
geüpload te worden. Vanaf hier is de publieke route stuk — de rest van de stappen hoort direct
94+
achter deze aan.
95+
96+
**2. De uitvraag krijgt de interne CA als bestand.**
97+
98+
De bijlage staat al in de catalogus van het project (`logius-internal-ca-root-cert`), alleen nog
99+
niet gekoppeld aan `uitvraag`:
100+
101+
```bash
102+
zadctl attachment assign logius-internal-ca-root-cert uitvraag \
103+
--provide-as file \
104+
--mount-path /etc/fsc/internal/logius/ca/root.pem
105+
```
106+
107+
**3. De uitvraag krijgt het anker en de URL's, in één stap.**
108+
109+
Per deployment, zodat de PR-previews op hun eigen (nog publieke) adres blijven werken tot ze mee
110+
verhuizen:
111+
112+
```bash
113+
OUTWAY=https://fsc-logius-logius-fscoutway.rig-prd-mpfb-8wh.svc.cluster.local:8443
114+
115+
zadctl env add -c uitvraag --deployment test \
116+
QUARKUS_TLS_OUTWAY_TRUST_STORE_PEM_CERTS=/etc/fsc/internal/logius/ca/root.pem \
117+
QUARKUS_REST_CLIENT_PROFIEL_SERVICE_TLS_CONFIGURATION_NAME=outway
118+
119+
zadctl env set -c uitvraag --deployment test \
120+
MAGAZIJN_A_URL="$OUTWAY" \
121+
PROFIEL_SERVICE_URL="$OUTWAY"
122+
```
123+
124+
`add` voor de twee nieuwe sleutels, `set` voor de twee die al bestaan — `add` op een bestaande
125+
sleutel is een conflict, geen overschrijving. Beide rollen standaard uit; met `--no-rollout` kun
126+
je ze stapelen en daarna één keer `zadctl deployment refresh test` doen.
127+
128+
**4. Verifiëren.**
129+
130+
```bash
131+
zadctl logs fsc-logius -c logius-fscoutway | grep -i "HTTPS server" # verwacht: starting HTTPS server
132+
zadctl logs test -c uitvraag | grep -iE "PKIX|SSLHandshake" # verwacht: niets
133+
```
134+
135+
**De outway logt vanaf nu elke twee seconden een TLS-fout, en dat hoort zo.** De readinessProbe
136+
is een `tcpSocket`-probe op 8443 met `periodSeconds: 2`; die opent een verbinding en sluit 'm
137+
meteen, wat een TLS-server als een afgebroken handshake ziet:
138+
139+
```
140+
ERROR ... "http: TLS handshake error from 10.x.x.x:39xxx: EOF"
141+
```
142+
143+
De probe slaagt gewoon (hij toetst alleen of de poort verbindingen aanneemt) en de deployment
144+
blijft Healthy. Filter erop bij het lezen van deze logs, en trap er niet in als je een écht
145+
handshake-probleem zoekt: dat komt van het adres van de uitvraag-pod en staat aan die kant als
146+
`PKIX path building failed`.
147+
148+
Daarna de functionele smoke: een ophaal-request door de keten
149+
`berichtenuitvraag → logius-fscoutway → magazijna-fscinway → berichtenmagazijn`, met een verse BSN
150+
zodat de sessiecache de keten niet maskeert. Let op dat de inway aan de overkant die van
151+
**magazijn-a** is (project `mpfm-w3h`, deployment `fsc-magazijna`): magazijn-a is een eigen peer.
152+
`logius-fscinway` is de ingang voor de diensten die logius zélf publiceert, zoals de
153+
profiel-service, en komt in dit pad niet voor. Een nieuwe transactie in beide txlogs is het bewijs
154+
dat het verkeer écht door de outway liep.
155+
156+
**5. De publieke ingress intrekken — punt van geen terugkeer.**
157+
158+
Werkt de interne route, haal dan "Publicatie op het web" van `logius-fscoutway` weg in de ZAD-UI.
159+
Hij is dan niet meer in gebruik, en een outway met een publiek adres is oppervlak dat niemand
160+
nodig heeft. Werk `verify-zad.md` bij als dit gebeurd is.
161+
162+
Doe deze stap pas als je de terugrol niet meer nodig denkt te hebben: het korte recept hieronder
163+
leunt op precies dat adres.
164+
165+
## Terugrollen
166+
167+
**Vóór stap 5.** Stap 1 en 3 zijn elkaars tegenhanger; draai ze samen terug:
168+
169+
```bash
170+
zadctl env unset -c logius-fscoutway LISTEN_HTTPS TLS_SERVER_CERT TLS_SERVER_KEY
171+
zadctl env unset -c uitvraag --deployment test \
172+
QUARKUS_TLS_OUTWAY_TRUST_STORE_PEM_CERTS QUARKUS_REST_CLIENT_PROFIEL_SERVICE_TLS_CONFIGURATION_NAME
173+
zadctl env set -c uitvraag --deployment test \
174+
MAGAZIJN_A_URL=https://logius-fscoutway-fsc-logius-mpfb-8wh.rig.prd1.gn2.quattro.rijksapps.nl \
175+
PROFIEL_SERVICE_URL=https://logius-fscoutway-fsc-logius-mpfb-8wh.rig.prd1.gn2.quattro.rijksapps.nl
176+
```
177+
178+
**Ná stap 5 werkt dat recept niet meer.** Die ingress-URL bestaat dan niet, dus je rolt terug naar
179+
een dood adres — en een terugrol draai je onder tijdsdruk. Zet in dat geval eerst "Publicatie op
180+
het web" op `logius-fscoutway` weer aan (ZAD-UI, `tls: standard`) en wacht tot de route antwoordt;
181+
pas daarna de commando's hierboven. Wil je die omweg vermijden, dan is de snellere terugval de
182+
env-vars leeghalen en `MAGAZIJN_A_URL`/`PROFIEL_SERVICE_URL` helemaal `unset`-en: de app valt dan
183+
terug op de component-aliassen, die rechtstreeks naar magazijn-a en de profiel-stub wijzen. Dat
184+
werkt zonder ingress, maar levert verkeer buiten de mesh om — zonder transactielogboek en zonder
185+
contractcontrole.
186+
187+
De bijlage uit stap 2 mag blijven hangen: zonder de env-var uit stap 3 doet een gemount
188+
CA-bestand niets. Laat 'm staan, dan is een tweede poging één commando korter.

‎demo/environment/logius/deploy/zad/upsert-peer.sh‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -183,6 +183,13 @@ LOGCTL_ALIASES=""
183183
# AUTHENTICATED interne poort (:9443) — `fsc-outway serve` eist beide (manager-internal-address +
184184
# controller-registration-api-address). Bewust anders dan de inway hieronder, die de
185185
# internal-UNAUTHENTICATED poort (:9444) gebruikt. Geen upstream: de outway is de afnemende kant.
186+
#
187+
# LISTEN_HTTPS zet TLS op de serve-poort (:8443) waarop `berichtenuitvraag` de outway aanroept.
188+
# Zonder dat is die poort plain HTTP en weigert de app het cluster-interne adres, want uitgaande
189+
# endpoints moeten buiten dev/test https zijn (BIO 13.2.1). Het serveert het INTERNE cert, niet
190+
# het group-cert: het group-cert is de mesh-identiteit richting andere peers, deze poort is de
191+
# lokale ingang voor onze eigen app. Datzelfde interne cert draagt al de Service-namen als SAN
192+
# (zie gen-csr.sh), dus zowel `fsc-logius-logius-fscoutway` als de FQDN valideren.
186193
LOGOUTWAY_ENV="$(printf '%s\n' \
187194
"LOG_TYPE=live" "LOG_LEVEL=info" \
188195
"NAME=logius-outway" \
@@ -196,6 +203,9 @@ LOGOUTWAY_ENV="$(printf '%s\n' \
196203
"TLS_ROOT_CERT=/etc/fsc/internal/logius/ca/root.pem" \
197204
"TLS_CERT=/etc/fsc/internal/logius/outway/cert.pem" \
198205
"TLS_KEY=/etc/fsc/internal/logius/outway/key.pem" \
206+
"LISTEN_HTTPS=true" \
207+
"TLS_SERVER_CERT=/etc/fsc/internal/logius/outway/cert.pem" \
208+
"TLS_SERVER_KEY=/etc/fsc/internal/logius/outway/key.pem" \
199209
"SELF_ADDRESS=https://${LOGOUTWAY_HOST_DISPLAY}:443" \
200210
"MANAGER_INTERNAL_ADDRESS=https://${LOGMGR_SVC}:9443" \
201211
"CONTROLLER_REGISTRATION_API_ADDRESS=https://${LOGCTL_SVC}:9443" \

‎demo/environment/logius/deploy/zad/verify-zad.md‎

Lines changed: 34 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -11,18 +11,22 @@
1111
interne mTLS-poorten een cluster-Service (`fsc-logius-logius-<comp>:<poort>`) krijgen.
1212
2. Cert-attachments gemount (zie `cert-manifest.md`) + "Publicatie op het web"
1313
(passthrough-TLS, modus 2) op logius-fscmgr **en** logius-fscinway ingesteld in de ZAD-UI. De
14-
outway logius-fscoutway blijft functioneel egress-only richting de mesh, maar heeft sinds
15-
2026-08-13 óók een eigen "Publicatie op het web" (`tls: standard`, geen passthrough — dit is
16-
niet de mesh-SNI-route, maar de lokale serve-poort `8443` waarop de `berichtenuitvraag`-app
17-
'm aanroept). Reden: de per-deployment tenant-baseline-NetworkPolicy in ZAD isoleert de
18-
`test`- en `fsc-logius`-deployment van elkaar (elke deployment mag alleen naar zichzelf +
19-
platform-namespaces, ongeacht dat ze in hetzelfde project/dezelfde namespace zitten); de
20-
ClusterIP-service `fsc-logius-logius-fscoutway:8443` is daardoor vanuit `test` onbereikbaar,
21-
terwijl verkeer via de ingress-controller wél is toegestaan. Nog te verifiëren: of `tls:
22-
standard` hier volstaat, of dat de serve-poort — net als manager/inway — passthrough (eigen
23-
cert) nodig heeft. Herzie deze publicatie zodra ZAD een manier biedt om gericht een
24-
NetworkPolicy-uitzondering tussen deployments binnen hetzelfde project te configureren; dan
25-
kan de outway weer zuiver intern (zonder publieke ingress) bereikt worden.
14+
outway logius-fscoutway is functioneel egress-only richting de mesh; zijn serve-poort `8443`
15+
is de lokale ingang waarop de `berichtenuitvraag`-app hem aanroept. Die poort draait TLS met
16+
het interne cert (`LISTEN_HTTPS=true`, zie `upsert-peer.sh`), zodat de app hem op zijn
17+
cluster-interne Service-naam mag aanroepen: uitgaande endpoints moeten buiten dev/test
18+
https zijn.
19+
20+
Het omzetten van de app naar dat interne adres is een cutover met een eigen draaiboek:
21+
[`cutover-interne-outway.md`](cutover-interne-outway.md).
22+
23+
De outway is verder egress-only en heeft **geen** publicatie op het web. Tussen 2026-08-13 en
24+
2026-08-19 had hij die wel (`tls: standard`, geen passthrough), omdat de per-deployment
25+
tenant-baseline-NetworkPolicy `test` en `fsc-logius` van elkaar isoleerde — elke deployment
26+
mag alleen naar zichzelf + platform-namespaces, ongeacht dat ze in hetzelfde project en
27+
dezelfde namespace zitten — waardoor de ClusterIP-service vanuit `test` onbereikbaar was en
28+
alleen de ingress-route overbleef. Met een gerichte NetworkPolicy-uitzondering (de
29+
platform-service `cross-domain-access`) verviel die omweg, en is de publicatie ingetrokken.
2630
3. Componenten herstart en boot-logs foutloos (zie `cert-manifest.md`, laatste sectie) — in het
2731
bijzonder GEEN `x509: certificate signed by unknown authority` meer op de controller: die
2832
bereikt de manager nu intern op `fsc-logius-logius-fscmgr:9443` (interne-PKI) i.p.v. de `:443`-group-ingress.
@@ -59,10 +63,19 @@ data-pad (`logius-fscoutway → inway → berichtenmagazijn`) bewijs je op ZAD t
5963
draaiende magazijn-a-peer (`demo/environment/magazijn-a/`). Dat vereist een geaccepteerd
6064
afnemer-contract (ServiceConnectionGrant) — nog niet onderdeel van dit ontwerp.
6165

62-
`berichtenuitvraag`'s `MAGAZIJN_A_URL` wijst dan naar `https://fsc-logius-logius-fscoutway:8443`
63-
(cluster-interne Service-DNS, zie `LISTEN_ADDRESS`/poort in `upsert-peer.sh`): peer en app delen
64-
het project `mpfb-8wh` en dus de namespace, en de ingress-URL-variant vervalt omdat de outway
65-
bewust niet op het web gepubliceerd is (zie stap 2 hierboven).
66+
`berichtenuitvraag`'s `MAGAZIJN_A_URL` wijst dan naar
67+
`https://fsc-logius-logius-fscoutway.rig-prd-mpfb-8wh.svc.cluster.local:8443` (cluster-interne
68+
Service-DNS; de Service heet `<deployment>-<component>` en de namespace is `rig-prd-<project>`).
69+
Twee dingen moeten daarvoor staan, en beide horen bij elkaar:
70+
71+
- de outway serveert TLS op die poort (`LISTEN_HTTPS=true`, stap 2);
72+
- de app kent het anker: `QUARKUS_TLS_OUTWAY_TRUST_STORE_PEM_CERTS` wijst naar het mount-pad
73+
`/etc/fsc/internal/logius/ca/root.pem`, een bijlage op het `uitvraag`-component (zo heet het
74+
component in ZAD; `berichtenuitvraag` is de applicatie). Zonder dat anker
75+
faalt de handshake — de interne CA staat niet in de JVM-default trust-store. Voor de
76+
profiel-service-client hoort daar
77+
`QUARKUS_REST_CLIENT_PROFIEL_SERVICE_TLS_CONFIGURATION_NAME=outway` bij; de magazijn-clients
78+
pakken de configuratie zelf op zodra hij bestaat.
6679

6780
### Inbound data-pad — profiel-service (lokaal bewezen, ZAD-apply is handmatig vervolgwerk)
6881

@@ -82,9 +95,11 @@ infrastructuur:
8295
3. Het zelfreferentiële `serviceConnection`-contract opnieuw opzetten tegen de ZAD-manager
8396
(zelfde POST+PUT-stroom als `consume-service.sh`, met de ZAD-groep-cert-thumbprint van
8497
`logius-fscoutway`).
85-
4. `PROFIEL_SERVICE_URL=https://fsc-logius-logius-fscoutway:8443` en
86-
`PROFIEL_SERVICE_GRANT_HASH=<content_hash uit stap 3>` als env-vars op de gedeployde
87-
`berichtenuitvraag`-app zetten (project `mpfb-8wh`).
98+
4. `PROFIEL_SERVICE_URL=https://fsc-logius-logius-fscoutway.rig-prd-mpfb-8wh.svc.cluster.local:8443`,
99+
`PROFIEL_SERVICE_GRANT_HASH=<content_hash uit stap 3>` en
100+
`QUARKUS_REST_CLIENT_PROFIEL_SERVICE_TLS_CONFIGURATION_NAME=outway` als env-vars op de
101+
gedeployde `berichtenuitvraag`-app zetten (project `mpfb-8wh`), naast het anker uit
102+
sectie (b).
88103
5. Een smoke voor het pad `berichtenuitvraag → logius-fscoutway → logius-fscinway → upstream`.
89104

90105
### Inbound data-pad — notificatieservice (lokaal bewezen, ZAD-apply is handmatig vervolgwerk)

0 commit comments

Comments
 (0)