NAV referansegruppemøte 5. mars 2024

NAV-ref Home

Tilstede:

• Peder Smart Sefland, HiVolda
• Rune Kittelsen, UiA
• Ingeborg Hellemo, UiT
• Nils-Arild Grav, NTNU
• Sigurd Refvik, UiO

• Knut-Helge Vindheim, Sikt, CNaaS
• Vidar Stokke, Sikt, CNaaS (tilstede bare under deler av møtet)
• Hanne Moa, Sikt
• Johanna England, Sikt
• Simon Oliver Tveit, Sikt
• Ilona Podliashanyk, Sikt
• Morten Brekkevold, Sikt

Forfall:

• Vidar Faltinsen, Sikt

Møtet blir avholdt som videokonferanse vha. Zoom, fra kl. 09:00 til 12:00.

Morten ønsker velkommen på vegne av Sikt.

Teamet er inne i siste uke av en pågående NAV-sprint, men det har ikke vært andre NAV-sprinter mellom forrige nav-ref og nå. Det er derfor kun utkommet en patch-release med bugfiser siden sist, versjon 5.8.4.

Pågående NAV-sprint har fokus på retting av problemer funnet under penetrasjonstestingen av NAV i slutten av november. Vi går gjennom noen av problemene som er funnet. Ingen av dem er av veldig alvorlig karakter, men vi unngår å referatføre detaljer inntil ting er løst.

Som nevnt på forrige møte, har en del teknisk gjeld som må gjøres opp for at NAV ikke skal bli hengende igjen på gamle, usikre eller ustøttede versjoner av avhengigheter. Dette vil dessverre gå på bekostning av ny funksjonalitet, men om vi ikke prioriterer dette, får vi heller ikke levert ny funksjonalitet. De primære målene her er:

• NAV må bli kompatibelt med Python 3.11, og senere også 3.12. Vi er nå inne i en runde med OS-oppgraderinger av verktøykasser fra Debian Buster til Debian Stable, som tar oss fra Python 3.7 til 3.9, slik at vi kan droppe støtten for 3.7. Men, den siste stable-utgaven av Debian er Debian Bookworm, og den kan vi ikke oppgradere verktøykassene til før NAV kan kjøre på Python 3.11. Akkurat dette kravet fører med seg et ras av endringer i underliggende biblioteker, og har også ringvirkninger for hvordan frontend i NAV fungerer, grunnet NAVs kobling til Foundation-rammeverket.

• Webgrensesnittet i NAV benytter mange håpløst utdaterte JavaScript-rammeverk, og noen av disse flagges i dag av diverse sikkerhetsscan i sektoren. Vi jobber nå for å innføre mer moderne metoder å dra inn tredjeparts JavaScript-biblioteker med spesifiserte versjoner (slik vi har gjort med Python i mange, mange år), fremfor å bundle/“vendor-e” inn spesifikke versjoner i NAV-kildekoden, men dette er et møysommelig arbeid som vil pågå over tid.

Kort rapport om Sikt og CNaaS-teamet besøk i Uganda, der det Ugandiske forskningsnettet RENU i disse dager lanserer sin egen CNaaS-tjeneste, som vil basere seg på bruk av NAV og potensielt også Argus.

På forrige møte nevnte NTNU og flere andre behov for systemer/grensesnitt for registrering av IoT-duppdingser, AV- og eller BYOD-utstyr, som ikke kan støtte interaktiv 802.1X-autentisering og må autentiseres med MAB. Det ble diskutert om dette var et behov som kunne dekkes av NAV.

SURFnet utvikler og bruker et system under navnet iotroam som kanskje kan brukes til dette. Dette har blitt nevnt under de jevnlige CNaaS-møtene mellom Sikt, SUNET og SURFnet. Vidar Stokke fra Sikts CNaaS-team har sett litt på iotroam og er invitert til nav-ref for å delta i en eventuell diskusjon om dette.

Dette er et tentativt agendapunkt for å følge opp VRF-diskusjonen fra referansegruppemøtet 6. september. UiT har ettersendt lenker til eksempler på uthenting av ARP-informasjon med REST-APIer i enkelte Cisco-modeller: https://community.cisco.com/t5/application-centric-infrastructure/how-to-massively-list-all-the-mac-adresses-related-to-an-aci/td-p/4063442

Som varslet, er ikke støtten for SNMPv3 i NAV 5.8 komplett. Blant annet støttes ikke CAM-innsamling på Cisco med SNMPv3 (#2811), ei heller SNMP trapmottak for SNMPv3 (#2755). I tillegg har CNaaS-teamet rapportert muntlig noen bugs i eksisterende funksjonalitet, som det ikke er laget skriftlig rapport på enda.

Det er ikke mye tid igjen i inneværende sprint til å jobbe videre med dette, men prioriteringen av SNMPv3 internt er fremdeles høyt, grunnet kontraktsbaserte hensyn i CNaaS-tjenesten.

Det kan nevnes at det viser seg å være et problem med støtte for de mest moderne sikkerhetsprotokollen i SNMPv3 på verktøykassen som fremdeles kjører Debian Buster, da det underliggende NET-SNMP-biblioteket i denne Debian-versjonen faktisk ikke støtter disse protokollene (som f.eks. AES). Dette vil rette seg så snart verktøykassene blir oppgradert.

Runde rundt “bordet”. Noen forhåndsinnmeldte saker:

• I et Cisco SDA-nett ser vi behov for status-uthenting av VN (=VRF) og SGT (Security Group Tag) fra svitsjeportene.
• For å tilfredsstille kravene i NTNU sitt Information Security Management System (ISMS) er det ønskelig med multi-faktor autentisering/MFA og sentral logg-tjeneste

Vi velger neste møtedato, ca. 3. juni (uke 23).

Morten ønsket velkommen på vegne av Sikt. Vidar Stokke kunne ikke møte fra start grunnet driftshendelser, men kom inn og presentert iotroam mot slutten av møtet. Knut-Helge Vindheim deltok som Vidars “vikar” under hele møtet.

Status for utvikling den siste tiden ble presentert, ihht. agenda.

Rapport fra penetrasjonstest av NAV/Verktøykasse ble gjennomgått. Et par av problemene dreier seg om uklar håndtering av tilgangsrettigheter til NAVs API for vanlige NAV-brukere (tilgang til API-et uten tokens, men med interaktiv innlogget sesjon). Dette er i samme klasse problem som er diskutert i tidligere navref-møter, men diskusjonen strekker seg tilbake til minst 2008, vist ved issue #1046.

AKSJON: Peder foreslår at gruppen holder et eget møte på et tidspunkt kun for å diskutere hvordan tilgangsstyring i NAV skal/bør fungere i fremtiden.

Før Vidar Stokke kom inn i møte, ble det diskutert at det fins minst to typer IoT-dingser: Personlige dingser og delte dingser. Et verktøy for registrering av utstyr som skal ha aksess må kunne kategorisere utstyr på denne måten.

Vidar Stokke kom inn og presenterte iotroam først etter vi var begynt med agendapunkt 3, men diskusjonen er referatført her. Vidar har ingen praktisk erfaring med iotroam enda, men det er et potensielt interessant verktør for våre CNaaS-leveranser.

iotroam betegner seg som “eduroam for IoT devices”: I korte trekk er iotroam en self-service portal for registring av enheter og/eller grupper av enheter som skal gis nettilgang, og potensielt til hvilke VLAN disse skal gis tilgang. Tilgang til Wi-Fi kan gis ved at registrert utstyr får tildelt sin egen pre-shared key . iotroam legger opp til å kunne sette opp en nasjonal, føderert infrastruktur med RADIUS-servere og RADIUS-proxies, på lik linje med eduroam, som gjør brukerne i stand til å roame mellom institusjoner med sine registrerte dingser.

Møtedeltakerne er i første omgang interessert i lokal bruk av et slikt verktøy på sin egen institusjon, ikke i roaming-delen. Vi anbefaler deltakerne å ta en nærmere titt på om iotroam er noe som kan understøtte deres behov, med eller uten videreutvikling. Sikt kan være interessert i å etablere en nasjonal infrastruktur for iotroam om interessen er stor nok.

Det er uklart om UiTs bruk av VRF faktisk ble presentert på nettmøtet før jul. UiTs umiddelbare bekymring var hvorvidt NAV ville trenge utvidelser for å hente fullstendig ARP-cache fra VRF-enablede Cisco-rutere, men erfaring tilsier at hele ARP-cachen kan hentes fra hovedinstansen.

Uansett er det viktigste ønsket fra UiT her at NAV kanskje bør ha en datamodell som viser hvilke VRF-er som fins på en boks. Her fins blant annet CISCO-VRF-MIB som kan slik info på Cisco. For Arista støtter NAV allerede ARISTA-VRF-MIB - ikke til å registrere hvilke VRF-instanser som fins, men nettopp for å oppnå fullstendig innsamling av ARP-cache, som ikke er fullstendig på hovedinstansen på Arista.

Dessuten bruker UiT Cisco ACI, og der fins det ikke noe SNMP-grensesnitt for å hente ut ARP-cache. Eksempelet som er vedlagt agenda viser hvordan man kan bruke ACIs REST-API for å hente ut dette. Dette peker videre på hvordan UiTs pull request #2613 for ARP-innsamling på PaloAlto-brannmurer kan være et verdifullt eksempel til gjenbruk på andre plattformer.

• I et Cisco SDA-nett ser vi behov for status-uthenting av VN (=VRF) og SGT (Security Group Tag) fra svitsjeportene.
  • NTNU “skraper” i dag dette ut fra SSH-oppkoblinger mot switcher i et egenutviklet system, og produserer en web-basert port-tabell der disse attributtene fremkommer. Nils-Arild viste kort demo.
  • Ønsker gjerne at NAV kan tilrettelegge for å ha med slike port-attributter, og samle dem inn der det er mulig.
  • AKSJON: Nils-Arild ettersender et screenshot fra port-tabell i nevnte verktøy, som kan fungere som inspirasjon/blikkfang og forklarende element til en NAV-issue.
  • AKSJON: Morten lager en issue som beskriver ønsket når Nils-Arild har ettersendt screenshot.

• MFA
  • NTNU ønsker også MFA-innlogging i NAV. Dette er allerede registrert som #2613.
  • Foreløpig viser utviklerteamet til både ferdigstilt og pågående arbeid som dokumenterer hvordan man kan integrere NAV med Feide-innlogging.
    • Ulempen med disse løsningene er at de gjør det umulig å logge inn med lokale brukere i NAV, man kan bare bruke Feide-brukeren.
    • En komplett løsning kan ikke tilbys før NAV støtter SAML eller OAuth2-innlogging internt. Dette er et langt lerret å bleke, da det forutsetter en tettere integrasjon mellom NAVs “legacy” brukerdatabase og Djangos brukerdatabase, som vil muliggjøre bruk av all mulig eksisterende mellomvare for autentisering på web (så vi slipper å vedlikeholde vår egen “hjemmesnekrede” MFA-løsning i NAV).
• Sentral logging
  • NTNU ønsker en del av NAV-loggene sendt til sin sentrale loggløsning - men aller helst ønsker de at NAVs audit log skal kunne sendes dit. NAVs auditlog fins i dag bare i NAV-databasen, og logges aldri til filsystemet. Hadde dette i tillegg vært logget til filsystemet, hadde det vært en smal sak å shippe disse loggene til en sentral loggserver med f.eks. et verktøy som Vector.
    • Eksisterende NAV-logger kan allerede shippes med et verktøy som Vector, som allerede fins på verktøykassen, og som brukes til å sende systemloggene på en verktøykasse til Sikts sentrale loggtjeneste.
    • AKSJON: Morten lager et issue i NAVs tracker på å også sende NAVs auditlog-meldinger til en Python-logger, slik at disse kan sendes til filsystem eller andre loggmottakere.

Har ingenting nytt å melde ut over det som ble diskutert under VRF-punktet lenger opp.

Ingen nye ønsker foreløpig.

Ingen nye ønsker foreløpig.

Ingen nye ønsker foreløpig.

Neste møte ble satt til Mandag 3. juni, klokken 12-15, på Zoom