✨ Mise en place des PodSecurityAdmission sur les namespaces clients #35
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(cherry-pick from #34)
Dans l'objectif de remplacer les podSecurityPolicy en prévision du passage en Kubernetes 1.26, il est nécessaire de mettre en place les nouvelles règles de sécurité.
Nous mettons en place par défaut un enforce sur la policy "restricted", avec un warning emis dès lors que l'applicatif ne respecte pas la policy "restricted" et réalisons par défaut l'émission d'un event d'audit lorsque la policy ne respecte pas le niveau "restricted".
Le choix restricted a été fait dans l'objectif d'avoir une politique sécurisée par défaut.
En raison de projets clients devant être en privileged, nous rendons possible l'ajout d'une liste de namespaces devant être valorisés à privileged. Nous émettons un log de type Warn pour souligner à un administrateur la particularité de configuration d'un namespace en particulier dans les logs de l'opérateur. Sans cette modification tous les namespaces clients sont considérés comme héritant de la politique par défaut.