Hvilken stor organisasjon kan si at de ikke har flaskehalser? At de ikke har noen problemer med å delegere ansvar, roller og oppgaver. Har deres organisasjon vurdert nøye hvor det stopper opp, hvem sin tid som bør vernes og hvordan? Noen ganger bør og kan ansvar delegeres for å unngå flaskehalser, men ofte må man håndtere at flaskehalser eksisterer og heller sørge for at det flyter. Flyt er noe man tar for gitt når det er der, men som man definitivt merker når det mangler. Det er flaskehalser overalt hvor det er mennesker involvert, men det betyr ikke at man må godta dem eller bruke dyre dyre dommer på å løse problemet.
I tillegg til vanlige Azure operasjoner og rådgivning hos mine kunder, liker jeg å kunne tilby enkle løsninger med kort time to market, så fort man oppdager at det knirker i maskineriet eller det kun drypper fra flaskehalsen.
Å ha ressurser som venter på svar er kostbart og frustrerende.
Vern om tiden til kjernepersoner
Det er ingen uvanlig situasjon at mye, ofte for mye og ikke minst mange, ansvar ligger hos enkeltpersoner. De har sentrale roller og er de eneste som kan utføre visse handlinger på ulike plattformer, samtidig som at de er de eneste som kan ta en rekke avgjørelser. De blir oversvømt i spørsmål, mailer og møteinvitasjoner, samtidig som at de må holde seg faglig oppdatert.
Eksempelet som utgangspunkt: Azure DevOps lisenser
Utviklere og andre ansatte kommer til en løsningsansvarlig for å få tilganger, men løsningsansvarlig har heller ikke alle rettighetene som skal til. Ansvarlig må sende en eller flere meldinger/mailer til sentral person 1, som når får tid, må logge inn og finne frem i tjenesten, DevOps, Azure AD, noe annet, alt ettersom.
Gruppebaserte tilganger og lik praksis
Jeg er glad i å styre tilganger med mest mulig lik praksis og det i dette tilfellet innebar det medlemskap i sikkerhetsgrupper i Azure AD. Man gir tilgang via gruppemedlemskap. I mitt tilfelle ble automasjonen laget for å lettere gi DevOps lisenser og ettersom group rules har noen pitfalls, måtte det nøye vurderes hva som var hensiktsmessig. Det viktig å påpeke at flyten ikke gir noen tilganger til kode. Løsningsansvarlig kunne og måtte invitere brukere til sine prosjekter, men lisenser må altså være på plass for å kunne dette. Jeg kunne ha satt opp at gruppene fikk prosjekttilganger gjennom grupper, men man mister også den fine viewen av når brukeren sist logget seg på i DevOps.
Power Automate + Logic Apps + Azure Functions
Jeg lagde en Power Automate Flow, en Logic App og brukte Azure functions som jeg allerede hadde laget for å gjøre Graph operasjoner.
Power Automate triggerflowen ble laget i Teams og Logic Appen i Azure, blant annet slik at denne kunne kalle på Azure Functions via managed identity. Jeg måtte blant annet finne ID-en til brukere som var eksterne og jeg måtte legge brukere til i riktig gruppe.
Triggerflowen kan deles på gjennom et Team eller deles individuelt slik at person 1 og person 2 har hver sin flow. Triggerflowen krever ikke ny innlogging. Man er allerede logget inn via Office.
I logic appen i Azure er "godkjenner" satt som en parameter. Det er ikke noe som person 1 eller 2 kan endre uten tilstrekkelige roller i Azure. Triggerflowene kan altså deles og endres på som ønskelig, men automasjonskomponentene i Azure er off limits.
Den som forespurte tilgangen får en melding i Teams når svaret er mottatt og tilgang gitt/nektet.
Start en handling fra Teams, få tillatelse fra en person med nok rettigheter og få noe til å skje i Azure.
Closing notes
Ønsker man å legge til en ny applikasjon i Microsoft er det en innebygget "admin consent" funksjonalitet. Ønsker man å bruke entitlement management, kan man også velge å sette opp dette. Det er mange veier til mål, men admin ønsket å unngå mail og få spørsmål i Teams.
Ettersom dette mini-sidequest oppdraget handlet om DevOps tilganger, vil jeg legge ved en liten advarsel frem til min neste artikkel kommer ut. DevOps group rules fungerer godt og er anbefalt metode for å gi lisenser for Enterprise selskaper, men som jeg nevnte så har det sine pitfalls, særlig når det kommer til opprydning. For eksempel: Du mister ikke lisensen når du mister gruppen. Jeg vil uansett anbefale å opprettholde en god praksis rundt at prosjektledere tar ansvar for sine prosjektmedlemmer og når noen ikke har prosjekter, skal de fjernes fra organisasjonen. Har de ikke vært logget inn på lenge, bør de fjernes og kan be om ny tilgang. Nå har det jo til og med blitt lettere!