This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-10-27
Channels
- # announcements (10)
- # beginners (95)
- # biff (2)
- # calva (33)
- # cherry (1)
- # clj-kondo (16)
- # clojure (96)
- # clojure-australia (1)
- # clojure-china (1)
- # clojure-europe (42)
- # clojure-filipino (1)
- # clojure-france (2)
- # clojure-hk (1)
- # clojure-indonesia (1)
- # clojure-japan (1)
- # clojure-korea (1)
- # clojure-my (1)
- # clojure-nl (1)
- # clojure-norway (24)
- # clojure-sg (11)
- # clojure-taiwan (1)
- # clojure-uk (1)
- # clojurescript (21)
- # cursive (22)
- # data-science (3)
- # events (7)
- # fulcro (3)
- # graalvm (4)
- # gratitude (6)
- # helix (11)
- # honeysql (7)
- # hoplon (1)
- # introduce-yourself (1)
- # jobs (2)
- # jobs-discuss (16)
- # lsp (15)
- # malli (14)
- # nbb (73)
- # practicalli (3)
- # reagent (8)
- # reitit (5)
- # releases (1)
- # ring (5)
- # rum (3)
- # sci (17)
- # scittle (7)
- # shadow-cljs (22)
- # tools-deps (26)
- # xtdb (9)
Jeg har ikke set på OPA, men vi har enn så lenge endt opp med noe deklarative policy greier, med mulighet for imperative escape hatches.
Telia begynte å innføre det men jeg følgte min clojure drøm før de lærte nok om hvordan det fungerer IRL
Jeg kjenner heller ikke til OPA, men er merkelig nok interessert nok i sånt til at jeg skal kikke på det ved anledning 😄
Vår modell er fritt modellert som et subset av AWS IAM sin tilgangsmodell, den syns jeg er innmari fin
(def service-config (merge {:service :workspace-service
::authorization-service/permission-holder-mapping-fn (authorization-service/entity-itself-contains-permission-holder core/id)
::authorization-service/policy
{:default authorization-service/admin-or-permission
:create authorization-service/custom
:delete {::authorization-service/action-policy authorization-service/admin
::authorization-service/permission {:action :admin}}}}
workspace-repo/config))
Er et eksempel på vår policyEtter hva jeg har lest, så funker OPA sånn at man kompilerer policyene til… noe, som så evalueres av enten et Go-bibliotek eller et WASM-bibliotek. Ikke helt JVM-vennlig altså. Men de har en ferdig serverprosess i Docker som man kan spinne opp som en egen tjeneste eller en sidecar, til hvilken man deployer de kompilerte policyene. Men nylig har det kommet mulighet for å kompilere policyene til et intermediate format (IR), som man kan evaluere selv. Noen har begynt på en slik Clojure-evaluator her: https://github.com/johanfylling/jarl/ Det hele er litt for omstendelig for mine behov akkurat nå, men jeg skal følge med på det i hvert fall.
Det blir som (auth-service/authorized? user action entity)
fra @slipset sin melding ovenfor - der ville hele OPA-greiene være gjemt inni den svarte boksen som er auth-service
.
Men min forståelse av OPA nå, er at det er mer enterprise-grade enn jeg trenger. Hvis du trenger å ha felles autorisasjonstjeneste for dusinvis av av tjenester, liksom.
Jepp. Fordelene med å bruke et rammeverk vil kunne inneholde:
1. Hvis du må snakke med andre systemer (som du kanskje ikke eier) så har du et kjent interface.
2. Hvis ideene bak rammeverket er velkjente, så er det mulig at det er enklere at flere (utviklere) forstår hva du snakker om enn hvis det er homebrew
Ulempene er at rammeverk ofte er mer generelle enn du trenger, kanskje er mer restriktive enn du ønsker (se vår custom
policy) Og at de kommer med Rust og Docker og annen misere.