Forvirrende warning om gjensidig manglende outbound access policy

[tronghn]

Dersom en applikasjon foo har satt opp inbound-regler for en konsument bar:

spec:
  accessPolicy:
    inbound:
      rules:
        - application: bar

og konsumenten bar ikke har satt opp gjensidige outbound-regler for foo, så blir dette vist som en warning hos fooi Console:

Traffic from bar in namespace <namespace> (<cluster>) is allowed by access policy, but bar does not have an outbound rule for foo.
Consult Nais Application reference - accessPolicy.

Burde dette ha vært en warning hos konsumenten (bar) og ikke hos produsenten (foo)?

Edit:

Use caset for denne typen warnings er at vi ønsker å informere tilbyderappen om potensielt ubrukte/unødvendige inbound policies. Det kan være noe uheldig at det markeres som en warning, siden det kan tolkes som "noe-som-ikke-fungerer-må-fikse-asap".

Eventuelt så kan meldingen kanskje endres slik at den:

• er eksplisitt på hva den forsøker å informere om
• kan dismisses hvis irrelevant

Relevante Slacktråder:

• https://nav-it.slack.com/archives/C050DP53VPH/p1736158270731859
• https://nav-it.slack.com/archives/C5KUST8N6/p1736151557881179

Relatert til #52.

[jhrv]

Jeg tenker at dette er en ganske riktig måte og løse det på. Ellers vil potensielt konsumenter kunne påvirkes med warnings som de ikke har kontroll på eller rår. Selv om det er litt søkt, og nok ikke vanlig at produsenter åpner mot konsumenter de ikke ønsker trafikk fra tenker jeg fortsatt det er riktigst.

Tenker også at konsumentene kan få tilsvarende warnings om de har åpninger mot produsenter som ikke har åpning mot de.
Tenker vel også at warning er et passe nivå, men kan kanskje argumentere for at det er en "TODO"/"info". Det er iallefall noe de bør rydde opp i da åpningen ikke har noen effekt og er et potensielt unødvendig sikkerhetshull.

Det kan godt hende meldingen bør se annerledes ut, og/eller at selve error/warn/info-opplegget i Console kan endres slik at dette blir mer forståelig. Og ref #52 bør det også fikses slik at vi ikke har noen falske positiver her.

Det sagt, det du nevner i https://nav-it.slack.com/archives/C050DP53VPH/p1736158270731859 er jeg helt enig i. Hvordan apper skal og bør kommunisere i og på tvers av clustere er ikke enkelt å skjønne, og det er spesielt komplisert i Nav når onprem er involvert. Her bør vi sette oss ned og se om vi kommer på en bedre og mer lettfattelig løsning.

[tronghn]

Jepp, det kan som du nevner være at vi bør ha noe informasjon på begge sider her.

Forvirringen i Console tror jeg nok ligger i at meldingen bare ble presentert for produsenten uten den kontekst om at vi forsøker å informere om en potensiell ubrukt eller unødvendig tilgang. På konsumenten sin side var alt hunky-dory, selv om det i teorien ville feilet ved kall via service discovery.

Den dypere problemstillingen her er jo kanskje at policiene er tvetydige nok til at vi ikke med sikkerhet kan si hva som er galt. Hvis produsenten har definert en inbound regel og konsument ikke har en innbyrdes outbound regel så er det jo flere måter å tolke dette på. Det kan bety at:

1. Konsumenten bruker ikke service discovery, eller
2. Konsumenten har glemt å legge inn en outbound regel, eller
3. Produsenten har glemt å rydde opp i en gammel regel, eller
4. Produsenten har definert en inbound regel før konsumenten har lagt til tilsvarende i outbound

Og det kan være at det er nok at vi dokumenterer og opplyser om disse, all den tid vi ikke kan si noe mer sikkert om hva de forsøker å gjøre.

[jhrv]

På konsumenten sin side var alt hunky-dory, selv om det i teorien ville feilet ved kall via service discovery.

Ja, så kan hende at ved å legge til en lignende advarsel på andre siden (for konsumenten) hadde vært nyttig.

Alle fire casene kan være tilfelle, men jeg vil påstå at for en produsent er alle disse "actionable". En åpning/policy de legger inn, bør komme fra et behov og fra noen form for kommunikasjon med sin konsument. I de fleste tilfellene, med unntak av nummer 4 burde produsent bare kunne slette åpningen og vente til behovet oppstår eller konsumenten tar kontakt.

@rbjornstad @thokra-nav tanker?