✨ Mise en place des PodSecurityAdmission sur les namespaces clients #36
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
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. La configuration est appliquée à travers le configmap de Kubi car c'est là qu'est toute la configuration du composant. Par conséquent, une modification de la configuration nécessite forcément un redémarrage de l'opérateur. (Peut être réalisé via Stakater).
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.
(cherrypick 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.
La configuration est appliquée à travers le configmap de Kubi car c'est là qu'est toute la configuration du composant. Par conséquent, une modification de la configuration nécessite forcément un redémarrage de l'opérateur. (Peut être réalisé via Stakater).