Policy Reporter Targets as CRDs

[mveitas]

Currently all configuration for targets such as email, slack, etc are all done in a central location. This requires teams make a contribution to the main policy-reporter configuration and deploy the changes.

Creating a CRD that describes a target would allow teams to manage their notifications in a self-service manner. An example below:

apiVersion: kyverno.io/v1alpha1
kind: PolicyReporterTarget
spec:
   slack:
      webhook: "https://hooks.slack.com/services/123..."
      skipExistingOnStartup: true
      filter:
         namespaces:
            include: ["team-a-*"]
         priorities:
            exclude: ["info", "debug"]
         policies:
            include: ["require-*"]

Centralized configuration of SMTP server configuration would be kept within the core configuration for the Policy Reporter

[fjogeleit]

Hey, thanks for your feedback.

It would make sense to offer this kind of flexibility.

My current focus is the new UI and cleanup of the current codebase. This requires most of my time right now. When this is finished I will think about the offering of CRDs to provide runtime configurations.

[mveitas]

If this is not something that is on your the immediate radar, I might get it started. Email reporting is the big thing that I want to be able to tackle as this is something that teams are looking for to periodically get a summary of any policy violations

[JimBugwadia]

@mveitas - the plan is to eventually move all configurations to CRDs. This work has not been committed to a release, so contributions are welcome! A brief KDP would be great to get the process started.

[mveitas]

With 50 or so teams running in our Kubernetes clusters, we want to allow teams to define the configuration for their email reports first and avoid having to deploy the policy reporter to update a team's configuration. We have some centrally managed metadata about teams that has Slack channels, email, etc that would drive creation of these CRDs as part of our platform. I'll create a separate issue to extraction of the email configuration along with a KDP

[aerosouund]

/assign

[aerosouund]

I will be sharing some opinions and ideas for changes to be done to the code itself as a starting point, these are changes that i believe will happen regardless of what the crd design ends up becoming.
These ideas can definitely change based on what we collectively decide and will get more refined after i study the code more

1- There will be a controller managing the new CRD, one of its dependencies is the Resolver type

2- The Resolver will keep a cache or a storage type of sorts to keep track of currently active targets

3- The controller will update this storage based on CRDs in the cluster, and this method will be called with CRDs found in this storage

func (r *Resolver) TargetClients() *target.Collection {
	if r.targetsCreated { // we will no longer have this be a singleton since this process will happen with each reconcile
		return r.targetClients
	}

	r.targetClients = r.TargetFactory().CreateClients(&r.config.Targets)  // this will be changed to be the storage, not the config
	r.targetsCreated = true                                              

	return r.targetClients
}

4- This method will receive an array of the CRD rather than a config, there will be a map of map[string]ClientFunc that will be looked up for each crd type (s3, slack.. etc) whats the proper function to use to initialize it, and there will be no check for the config being nil of course

func (f *TargetFactory) CreateClients(config *target.Targets) *target.Collection {
	targets := make([]*target.Target, 0)
	if config == nil {
		return target.NewCollection()
	}

	
	targets = append(targets, createClients("Loki", config.Loki, f.CreateLokiTarget)...)
	targets = append(targets, createClients("Elasticsearch", config.Elasticsearch, f.CreateElasticsearchTarget)...)
	targets = append(targets, createClients("Slack", config.Slack, f.CreateSlackTarget)...)
	targets = append(targets, createClients("Discord", config.Discord, f.CreateDiscordTarget)...)
	targets = append(targets, createClients("Teams", config.Teams, f.CreateTeamsTarget)...)
	targets = append(targets, createClients("GoogleChat", config.GoogleChat, f.CreateGoogleChatTarget)...)
	targets = append(targets, createClients("Telegram", config.Telegram, f.CreateTelegramTarget)...)
	targets = append(targets, createClients("Webhook", config.Webhook, f.CreateWebhookTarget)...)
	targets = append(targets, createClients("S3", config.S3, f.CreateS3Target)...)
	targets = append(targets, createClients("Kinesis", config.Kinesis, f.CreateKinesisTarget)...)
	targets = append(targets, createClients("SecurityHub", config.SecurityHub, f.CreateSecurityHubTarget)...)
	targets = append(targets, createClients("GoogleCloudStorage", config.GCS, f.CreateGCSTarget)...)

	return target.NewCollection(targets...)
}

Let me know your thoughts, I will also be investigating how this aforementioned store will look like, and how to keep track of what clients you sent messages to in light of the new structure