InseeFrLab / InseeFrLab/onyxia-api

Security : move away from "cluster-admin" everywhere

Aperta
#72 0 commenti 3 reazioni 0 assegnatari Vedi su GitHub
security
Lingua principale
Java
Stelle
34
Fork
34
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Descrizione

Currently, `Onyxia-api` do everything (both `kubectl` and `helm`) using a single service account that is supposed to be cluster-admin.
Here are some improvements we could make :
* [x] Every regular `kubectl` and `helm` calls should be made using user's permissions
* [ ] Onboarding (creating user's namespace, applying permissions ...) should be done using a separate service account and preferably done in another process / pod (externalize the onboarding process as a standalone API ?)
* [ ] Try to reduce or at least refine and explicit permissions needed for the onboarding feature. Currently, it defaults to creating a cluster-admin service account which is probably too much

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Direzione di ricerca

Start by tracing the Onyxia-api paths that make kubectl and helm calls and the onboarding flow that creates namespaces, permissions, and service accounts. Map the current cluster-admin dependency first; done means onboarding uses a separate identity and its required permissions are explicitly reduced or refined.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
helm, java, kubernetes
Ambito
authorization, infrastructure, security
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Ferma
Chiarezza
Abbastanza chiara
Idoneità per principianti
25/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.