OliverMKing commented 1 month ago

Description

This PR adds validation to our managed resources to ensure they are following Kubernetes best practices. We accomplish this by scanning our fixtures which represent the resources that we manage. Unfortunately, there's no tool that scans manifests with a complete library of best practices built in. We had a few options

SafeGuards. Would be great to use since we (AKS) maintain this and can collaborate with SafeGuards team. Will likely switch to this sometime in the future. Security best practices and other ones are being added.
ShieldGuard. Also maintained by AKS. Doesn't have any best practices built into the OSS version so we'd have to maintain our own fully. This also doesn't export their Go code so we can't call it within our unit tests which is a negative.
Gatekeeper / Gator. Exports code so we can call them through unit tests. We have to define some parts of how best practices apply but they have a library we pull from so we get most things out of the box.

We chose Gatekeeper for now. See the doc added to this PR for information on what we pull automatically and what we have to define.

Along with implementing these tests there were a few other things we had to do

Swap our fixtures from json to yaml. Gatekeeper / Gator doesn't handle json manifests stored in the same file. Yaml is easier to read anyways
Update a few dependencies (and make super minor changes to handle any breaking changes based on these bumps)

When reviewing this PR note that the files in pkg/manifests/policy/manifests/templates are pulled directly from the Gatekeeper Library with no changes. It may be good to view those separately so you can digest the contents of this PR better. This is a large PR but the majority of the diff is due to autogenerated things like fixtures switching from json to yaml and the autopulled templates.

Type of change

Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?

This is a testing improvement.

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules