feat: move constraints to gatekeeper

Package Owner Merge Request

Package Changes

Releases:

• https://repo1.dso.mil/platform-one/big-bang/apps/core/cluster-auditor/-/releases/0.3.0-bb.0
• https://repo1.dso.mil/platform-one/big-bang/apps/core/policy/-/releases/3.4.0-bb.4
• https://repo1.dso.mil/platform-one/big-bang/apps/core/policy/-/releases/3.4.0-bb.3
• https://repo1.dso.mil/platform-one/big-bang/apps/core/policy/-/releases/3.4.0-bb.2
• https://repo1.dso.mil/platform-one/big-bang/apps/core/policy/-/releases/3.4.0-bb.1

Moving OPA Constraints from cluster-auditor to OPA Gatekeeper package:

• https://repo1.dso.mil/platform-one/big-bang/apps/core/cluster-auditor/-/merge_requests/43
• https://repo1.dso.mil/platform-one/big-bang/apps/core/policy/-/merge_requests/50
• https://repo1.dso.mil/platform-one/big-bang/apps/core/policy/-/merge_requests/49
• https://repo1.dso.mil/platform-one/big-bang/apps/core/policy/-/merge_requests/48
• https://repo1.dso.mil/platform-one/big-bang/apps/core/policy/-/merge_requests/46

Documentation only:

• https://repo1.dso.mil/platform-one/big-bang/apps/core/policy/-/merge_requests/47

Additional Details

Constraints are now called as post-install hooks inside OPA Gatekeeper. Flux handles this appropriately with the Helm Release.

Known issues or expected conflicts?

It is unclear what happens to CRDs already created with cluster-auditor when OPA gatekeeper upgrades.

Closes https://repo1.dso.mil/platform-one/big-bang/bigbang/-/issues/490

added clusterAuditor gatekeeper labels

changed the description

added 4 commits

• cf0dd9b8...ce73d47d - 3 commits from branch master
• bdd7c35a - Merge branch 'master' into 'move-constraints-to-opa'

Compare with previous version

added statusreview label

changed milestone to %1.11.0

resolved all threads

resolved all threads

added 1 commit

• d406b8b6 - Including addl constraint for service account

Compare with previous version

approved this merge request

It is unclear what happens to CRDs already created with cluster-auditor when OPA gatekeeper upgrades.

This worries me...can we at least test an install of BB from master then upgrade to this branch and see what happens with the old CRDs? They should get deleted if they were deleted from cluster-auditor, but I have noticed CRDs can be weird with that...

unapproved this merge request

added statusdoing label and removed statusreview label

marked this merge request as draft

added 1 commit

• 2eb525d8 - fix(gatekeeper): bump to fix upgrade issue

Compare with previous version

added statusreview label and removed statusdoing label

resolved all threads

changed the description

marked this merge request as ready