✨ Mise en place des PodSecurityAdmission sur les namespaces clients #33
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
November 30, 2023 17:06
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é. A ce jour, en lien avec cette documentation : URL://pages/viewpage.action?pageId=228069521 Nous mettons en place par défaut un enforce sur la policy "baseline", 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". L'objectif est d'effectuer une bascule en souplesse des projets clients ne respectant pas en totalité la règle restricted (en rapport avec la manière dont son run les applications sur les clusters). Dans un premier temps, les projets pourront se voir autoriser des droits plus importants, mais l'objectif est de les prévenir que ces actions ne respectent pas les best-practices.
Sans cette modification tous namespaces clients sont considérés comme héritant de la politique par défaut.
Whisper40
force-pushed
the
podsecurity-admission
branch
from
fa27575 to
82767e4
Compare
|
MR (meme contenu) remplacée par : #34 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
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é.
A ce jour, en lien avec cette documentation : URL://pages/viewpage.action?pageId=228069521
Nous mettons en place par défaut un enforce sur la policy "baseline", 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".
L'objectif est d'effectuer une bascule en souplesse des projets clients ne respectant pas en totalité la règle restricted (en rapport avec la manière dont sont run les applications sur les clusters).
Dans un premier temps, les projets pourront se voir autoriser des droits plus importants, mais l'objectif est de les prévenir que ces actions ne respectent pas les best-practices.