NREC funderinger

Forvaltning

Slettede brukere

Brukere slutter og slettes ved universitetene. I dag har vi ingen automatikk eller varsling for å slette disse brukernes prosjekter og ressurser i prosjektene.

Følgende bør på plass:

  • Når en bruker slettes ved en institusjon skal brukerens DEMO- og PRIVATE-prosjekter slettes. Alle ressurser i disse prosjektene skal også slettes (instanser, volumer, DNS-soner m.m.)
  • Slettede brukere skal ikke være medlem i delte prosjekter. Dersom en slettet bruker har tilgang til et delt prosjekt skal tilgangen fjernes
  • Slettede brukere skal ikke være admin for delte prosjekter. Dersom det ikke er andre brukere med tilgang til prosjektet skal prosjektet og ressursene slettes. Dersom det finnes andre brukere med tilgang til prosjektet skal disse kontaktes med formål å finne en ny admin (kontaktadresse)

Alt dette kan automatiseres, med unntak av utskifting av admin som beskrevet i siste punkt. Automatisering forutsetter at vi har en trygg og forutsigbar måte å verifisere at en bruker er slettet ved institusjonen.

Policy for HPC

HPC-ressurser, spesielt dedikerte ressurser, er dyre. Vi har en policy som sier at slike ressurser skal brukes, men vi har i dag ingen overvåkning eller automatikk rundt dette. Vi er derfor avhengig av at brukerne selv håndhever HPC-policy, det er ikke optimalt.

Vi har i dag ingen enkelt måte å overvåke tildelingen av ressurser til HPC-formål. Dersom en bruker spør om det er plass til å kjøre en ressurs av en viss størrelse må vi grave for å finne ut dette. Det bør dessuten være mulig for brukerne å selv se hva som er tilgjengelig av dedikerte HPC-ressurser.

Følgende bør på plass:

  • En grafisk fremstilling av dedikerte HPC-ressurser, som forteller på en enkel måte hva som er opptatt og ledig på compute-nodene for HPC. Her må det tas hensyn til NUMA-noder. Denne grafiske fremstillingen bør være tilgjengelig for brukerne og skal gi et nøyaktig øyeblikksbilde over situasjonen for HPC-ressurser.
  • Policyen for bruk av HPC-ressurser må håndheves. Her kan Openstack-komponenten "Congress" brukes for å definere en policy, samt regler for hva som skal skje dersom policy ikke overholdes.

Disse tingene kan automatiseres, men det er potensielt mye arbeid og ingen lavthengende frukt.

Metadata for prosjekter

Det bør på plass metadata for alle prosjekter som sier hvilken institusjon som "eier" prosjektet. Dette er allerede vedtatt men er foreløpig ikke på plass. Slik metadata gir oss mulighet for enkelt å iverksette ny automatikk.

Periodisk varsling til brukerne om brukte ressurser

Vi antar at mange av brukerne tester og leker litt med NREC, og tar i bruk ressurser, f.eks. ved å kjøre instanser som de så glemmer. Det bør iverksettes en periodisk varsling til brukerne om hvilke prosjekter de har og hva prosjektene brukes av ressurser:

 

  • Prosjekter (inkl. admin, kontaktadresse, tilganger)
  • Instanser
  • Volumer
  • DNS-soner
  • Images

Brukerne bør anmodes om å slette ressurser som ikke er i bruk, slik at ressursene tilgjengeliggjøres for andre brukere, samt at de ikke utgjør en sikkerhetsrisiko idet de ikke vedlikeholdes aktivt.

Kostnadsberegning

Det bør synliggjøres for brukerne at NREC har en kostnad, og at deres bruk av NREC-ressursene også har en kostnad. Selv om 99% av brukerne
ikke skal betale for bruk av NREC bør kostnaden synliggjøres. Følgende bør på plass:

  • Openstack-komponenten "Cloudkitty" kan synliggjøre kostnaden over tid for brukernes ressurser. Samtidig bør det gjøres veldig klart for brukerne at de under normale omstendigheter ikke skal betale for bruk av NREC.

En fordel ved denne tilnærmingen er at det blir potensielt enklere å beregne kostnad for betalende kunder.

Policy for demo-prosjekter

Det bør på plass en policy for demo-prosjekter. Detaljene kan diskuteres, men i hovedsak bør det være noe slikt som:

  • Instanser i demo-prosjekter skal ha en maks levetid, f.eks. 3 måneder.
  • Når levetiden nås skal instansen automatisk slettes.
  • Når instansen slettes skal brukeren varsles.

Iverksetting av ny policy må gjøres skånsomt og med god varsling. Policyen skal håndheves 100% automatisk.

Enddate for prosjekter

Endel prosjekter har satt en enddate. Vi har i dag ingen fast oppfølging av prosjekter som har nådd sin enddate. Dette kan både binde opp ressurser som kunne vært frigjort, samt utgjøre en sikkerhetsrisiko idet brukeren kan feilaktig anta at prosjektet forsvinner og instansene ikke lenger trenger vedlikehold.

Følgende bør på plass:

  • En måned før enddate blir brukeren (admin for shared projects) varslet per e-post om at prosjektet når enddate om 1 mnd. Brukeren må kontakte NREC support for ev. forlengelse.
  • På dato for enddate blir alle brukerne for prosjektet varslet om at prosjektet kommer til å bli slettet innen kort tid. Admin må kontakte NREC support for ev. forlengelse.
  • En måned etter enddate blir prosjektet og alle tilhørende ressurser slettet.
  • Ved sletting må det sjekkes om prosjektet har API-only-brukere, og det må i så fall håndteres.

Det aller meste av dette bør skje automatisk.

Self-service

Dette bør være et langsiktig mål. Det som foreslås her er å utvikle en selvbetjeningsportal der brukerne selv kan gjøre f.eks.:

  • Legge til eller fjerne prosjektmedlemmer
  • Endre enddate
  • Endre kvote for prosjekter

Løsningen bør være modulær og fleksibel, slik at det er mulig å legge til flere ting etterhvert. Det bør være automatisk godkjenning av noen elementer (f.eks. legge til prosjektmedlemmer), mens andre ting må godkjennes av NREC (f.eks. økning av kvote).

Sikkerhet

Idet NREC brukes av flere og flere brukere, og til flere tjenester og ulike formål, opplever vi at antallet sikkerhetshendelser øker. Dette skjer fordi brukerne setter opp tjenester i NREC uten at tjenestene er tilstrekkelig sikret. Det er flere årsaker til at dette skjer, men den viktigste årsaken er at en IaaS har et iboende problem ved at den tillater hvem som helst å sette opp komplekse tjenester. Det er ingen krav til kompetanse, og mange brukere er ikke klar over hva det innebærer at kunden (brukeren) har ansvaret for all drift og sikkerhet på OS-nivå og opp.

Dette er en kompleks problemstilling og det finnes ikke en enkel løsning på problemet. Vi kan minimere problemet ved å iverksette endel tiltak:

  • Bedre og tydeligere dokumentasjon til brukerne om hva NREC skal brukes til og hva som forventes av brukerne. Brukerne må opplæres til å forstå hva det innebærer at de har ansvaret for sikkerheten, og rettledes til å ta riktige valg i forhold til sin egen kompetanse.
  • Opplæring av IT-avdelingene (lokal og sentral) internt på lærestedene (UiO og UiB) slik at IT-ansatte kan gi gode råd til sine brukere ang. NREC eller alternativer.
  • Bedre og mer overvåkning for å avdekke anomalier. Overvåkning for å avdekke anomalier er komplekst og vanskelig, men det første steget vil være å få på plass langt mer overvåkning og grafing av trender enn det vi har i dag.
  • Sjekke hvorvidt Uninett kan bidra fra nett-siden. All trafikk inn og ut av NREC går via Uninett, og det kan tenkes at Uninett kan bidra med automatisk analyse av nettrafikken for å avdekke potensielt misbruk eller kompromitterte maskiner.
  • Strømlinjeforme policies og kommunikasjonslinjer ifm. hendelser. Kommunikasjonlinjene ved sikkerhetshendelser er i dag uklare. Det er flere sikkerhetsgrupper og avdelinger involvert (IT-sikkert ved UiO, UiB, Uninett og IT-avdelingene ved UiO, UiB).

 

Publisert 23. feb. 2021 08:17 - Sist endret 23. feb. 2021 08:45