gatekeeper-library icon indicating copy to clipboard operation
gatekeeper-library copied to clipboard

Any interest in policies/constraints that apply to custom resources?

Open Speeddymon opened this issue 1 year ago • 6 comments

Hi team,

I've got a number of use-cases for creating policies that apply to custom resources added to clusters and I wanted to gauge interest from the community on whether anyone might find such a thing useful and where it should live?

For example, in one cluster, I'm running Crossplane which creates kind: Provider resources you can apply to the cluster. Those can in turn install many other kinds of custom resources. For example if I installed the "azure compute provider", then new apiGroups and kinds are created in the cluster and I can deploy resources under those which then interact with Azure to provision VMs.

Continuing the example, I'd like to ensure that an azure VM created by Crossplane has certain parameters set, and Gatekeeper will block the VM manifest from being applied to my Crossplane cluster (thus blocking the deployment to Azure) if the parameters don't match what I set.

Would the team here be willing to accept such submissions, perhaps under a ./library/crossplane/<provider-family>/<provider> directory structure?

Conversely, I have some clusters which don't make use of any custom resources aside from those created by Gatekeeper and the constraint templates. It would make sense to create a policy that prevents deployment of kind: CustomResourceDefinition resources outright (except for the ones created by Gatekeeper itself). This would provide greater protection to a lot of this library's users when they don't make use of any other custom resources other than those provided by Gatekeeper and this library.

I ask all of this because in addition to Crossplane, I also use Flux, Traefik Ingress Controller, Cert-Manager, and others; and I want to create constraints around the custom resources from each of those. I suspect once others see these types of constraint templates and constraints created, they might offer contributions here for the projects they use which I don't, and we can make a more comprehensive set of policies that can help teams using various OSS projects to protect their custom resources manifests from those OSS projects as well as their built-in resources.

One such example constraint I can think of right away is the ability to limit what values are used in those above-mentioned kind: Provider resources, in order to prevent either a malicious provider, or a provider that a team wants to disallow for whatever reason, from being used in the first place, which prevents the provider's custom resources from being created in the cluster.

Speeddymon avatar Dec 13 '23 17:12 Speeddymon

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Feb 13 '24 02:02 stale[bot]

@Speeddymon Thanks tor opening this issue! You might also want to open an issue in each respective projects to get interest and support. Having the policies within the projects might be better for discovery and keeping them up to date.

ritazh avatar Feb 13 '24 14:02 ritazh

Hi @ritazh

I will definitely consider to submit some example policies to the upstream teams; however my experience with OSS submissions like this has usually been met with resistance from the teams because they don't want to have to expand their support coverage (which I totally understand).

If you don't think a CRD policy library is a good fit for OPA org; I understand. Given the resistance upstream I had really hoped to avoid creating a "third party" CRD policy project; but I may give it a go anyways and who knows, maybe some people will come contribute their expertise in Rego and whatever CRD resources they are trying to protect, and make it something great.

Speeddymon avatar Apr 01 '24 14:04 Speeddymon

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Jun 01 '24 03:06 stale[bot]

@Speeddymon, I was facing the same challenge, and I just found the KICS project: https://docs.kics.io/latest/platforms/#crossplane

I haven't tried it yet, but it seems that it'd be possible to contribute such policies to KICS.

panasenco avatar Jun 04 '24 20:06 panasenco

Hi @panasenco! Thanks. Yes, I use KICS myself. The goal here was to add these policies into the library so that they can be used in Gatekeeper for administrative control to prevent developers who might be using automation that has cluster admin privileges from installing CRDs without a review by the team running the cluster. :)

Speeddymon avatar Jun 13 '24 14:06 Speeddymon

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Aug 12 '24 22:08 stale[bot]