Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supervise Existing Policies Before Validating New Deployments #2

Open
ElMarioVI opened this issue Nov 15, 2024 · 1 comment
Open

Supervise Existing Policies Before Validating New Deployments #2

ElMarioVI opened this issue Nov 15, 2024 · 1 comment

Comments

@ElMarioVI
Copy link
Member

Currently, Admitik validates or modifies Kubernetes resources based on conditions defined through Helm templates. However, we need to extend functionality to ensure policies are audited and supervised on already deployed resources before validating any new deployments.

Requirements:

  • Develop a feature to allow Admitik to audit and evaluate policies on existing resources within the Kubernetes cluster.
  • Ensure this audit happens prior to validating new resources to maintain consistency and compliance across the environment.
  • Provide detailed reports or logs highlighting policy compliance status, including any violations or improvement areas.

This enhancement will enable more proactive and comprehensive policy management across both existing and future resources in the cluster.

@achetronic
Copy link
Member

achetronic commented Nov 22, 2024

Hi there @ElMarioVI !

How are your expectations on this feature? (the expected behavior, etc)

Currently, the ClusterAdmissionPolicy supports two modes: Enforce and Permissive, and for each captured watched resource, it triggers a request against a webserver that process the conditions, and decides if it's accepted or not to enter

During the conditions evaluation, several useful things are injected, such as .object or .oldObject (in case of updates), so this allows you to compare it against even the rest of all the resources of the same kind.

Let's talk about your request. From my POV, if it needs to run in the background periodically or so, we can not inject mentioned objects, as they don't exist. That being said, we could inject the .sources in the same way, so you should iterate on them, and perform actions to have such a report, or similar as an output.
May be it should be a different resource, something as ClusterPeriodicReviewPolicy or something similar.

It that what you expect or covering your needs? what is the use case you detected?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants