User Tools

Site Tools


nav-ref:navref_050324

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
nav-ref:navref_050324 [2024/03/04 19:28]
morten snmpv3
nav-ref:navref_050324 [2024/03/06 12:03] (current)
morten 1. referatutkast
Line 4: Line 4:
  
  
-Innkalt:+Tilstede:
  
   * Peder Smart Sefland, //HiVolda//   * Peder Smart Sefland, //HiVolda//
Line 12: Line 12:
   * Sigurd Refvik, //UiO//   * Sigurd Refvik, //UiO//
  
-  * Vidar Stokke, //Sikt, CNaaS// +  * Knut-Helge Vindheim, //Sikt, CNaaS// 
-  * Vidar Faltinsen, //Sikt//+  * Vidar Stokke, //Sikt, CNaaS// (tilstede bare under deler av møtet)
   * Hanne Moa, //Sikt//   * Hanne Moa, //Sikt//
   * Johanna England, //Sikt//   * Johanna England, //Sikt//
Line 19: Line 19:
   * Ilona Podliashanyk,​ //Sikt//   * Ilona Podliashanyk,​ //Sikt//
   * Morten Brekkevold, //Sikt//   * Morten Brekkevold, //Sikt//
 +
 +Forfall:
 +
 +  * Vidar Faltinsen, //Sikt//
  
  
Line 63: Line 67:
 == SNMPv3 == == SNMPv3 ==
  
-Som varslet, er ikke støtten for SNMPv3 i NAV 5.8 komplett. ​ Blant annet støttes ikke CAM-innsamling på Cisco med SNMPv3 ([[https://​github.com/​Uninett/​nav/​issues/​2811|#​2811]]),​ ei heller SNMP trapmottak for SNMPv3 ([[https://​github.com/​Uninett/​nav/​issues/​2755|#​2755)).  I tillegg har CNaaS-teamet rapportert muntlig noen bugs i eksisterende funksjonalitet,​ som det ikke er laget skriftlig rapport på enda.+Som varslet, er ikke støtten for SNMPv3 i NAV 5.8 komplett. ​ Blant annet støttes ikke CAM-innsamling på Cisco med SNMPv3 ([[https://​github.com/​Uninett/​nav/​issues/​2811|#​2811]]),​ ei heller SNMP trapmottak for SNMPv3 ([[https://​github.com/​Uninett/​nav/​issues/​2755|#​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 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.
Line 76: Line 80:
  
   * I et Cisco SDA-nett ser vi behov for status-uthenting av VN (=VRF) og SGT (Security Group Tag) fra svitsjeportene.   * I et Cisco SDA-nett ser vi behov for status-uthenting av VN (=VRF) og SGT (Security Group Tag) fra svitsjeportene.
-  * SNMPv3-status:​ Noe nytt om fremdrift rundt manglende støtte for lesing av CAM-tabeller?​ 
-  * IPAM oppleves som mer og mer treg (?). Mulig det bare er et lokalt behov for reindeksering hos oss. 
   * For å tilfredsstille kravene i NTNU sitt Information Security Management System (ISMS) er det ønskelig med multi-faktor autentisering/​MFA og sentral logg-tjeneste ​   * For å tilfredsstille kravene i NTNU sitt Information Security Management System (ISMS) er det ønskelig med multi-faktor autentisering/​MFA og sentral logg-tjeneste ​
  
Line 86: Line 88:
 ===== Referat ===== ===== Referat =====
  
-Kommer.+=== 0Velkommen/​Innledning === 
 + 
 +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. 
 + 
 +=== 1. Presentasjoner/​Status === 
 + 
 +Status for utvikling den siste tiden ble presentert, ihht. agenda. 
 + 
 +== Penetrasjonstest av NAV == 
 + 
 +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 [[https://​github.com/​Uninett/​nav/​issues/​1046|#​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. 
 + 
 +=== 2. Fokus for videre utvikling/​tilbakemelding === 
 + 
 +== iotroam == 
 + 
 +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 [[https://​www.surf.nl/​en/​services/​iotroam|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. 
 + 
 +== VRF på UiT? == 
 + 
 +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 [[https://​github.com/​Uninett/​nav/​pull/​2613|UiTs pull request #2613 for ARP-innsamling på PaloAlto-brannmurer]] kan være et verdifullt eksempel til gjenbruk på andre plattformer. 
 + 
 +=== 3. Nye ønsker og innspill fra gruppen === 
 + 
 +== NTNU == 
 + 
 +  * 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 [[https://​github.com/​Uninett/​nav/​pull/​2613|#​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 [[https://​vector.dev/​|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. 
 + 
 +== UiT == 
 + 
 +Har ingenting nytt å melde ut over det som ble diskutert under VRF-punktet lenger opp. 
 + 
 +== UiA == 
 + 
 +Ingen nye ønsker foreløpig. 
 + 
 +== UiO == 
 + 
 +Ingen nye ønsker foreløpig. 
 + 
 +== HiVolda == 
 + 
 +Ingen nye ønsker foreløpig. 
 + 
 +=== 4. Neste møte === 
 + 
 +Neste møte ble satt til **Mandag 3. juni, klokken 12-15, på Zoom**
  
nav-ref/navref_050324.txt · Last modified: 2024/03/06 12:03 by morten