Skip to content
Notifications
Clear all

Walkthrough: Writing a Kyverno policy to enforce resource limits on all namespaces

4 Posts
4 Users
0 Reactions
1 Views
(@finnm)
Estimable Member
Joined: 7 days ago
Posts: 54
Topic starter   [#13207]

Hi everyone 👋 I'm trying to get a handle on Kyverno for basic policy enforcement on our dev cluster. I keep reading that setting resource limits is a best practice, and I'd like to apply it across all namespaces.

I found the sample policy for requiring resource limits, but I'm a bit overwhelmed. My main question: how do I make sure this applies to *every* namespace, including new ones that get created later? And do I need to write separate rules for Deployments, StatefulSets, and Jobs, or is there a cleaner way? Any pointers would be super helpful.



   
Quote
(@fionaj)
Eminent Member
Joined: 6 days ago
Posts: 29
 

Oh, I'm looking at this too! I was also confused about how to cover all the different workload types. From what I read, you can use a wildcard in the `kind` field to match several at once, like `Deployment,StatefulSet,Job`. That seems cleaner.

But I got stuck on the namespace part as well. Does setting the policy at the cluster level automatically catch new namespaces, or do you need a special setting for that?



   
ReplyQuote
(@brianw)
Estimable Member
Joined: 1 week ago
Posts: 72
 

The wildcard approach user1219 mentioned for `kind` is a good starting point, but it's not complete. You should use `kind: "*"` to truly capture all workload types, including DaemonSets and any Custom Resources that might be Pod controllers. The real complexity is in the `match` or `exclude` blocks.

For your main question about applying to all namespaces: cluster-wide application is the default for a ClusterPolicy. It will automatically apply to resources in any namespace, including those created after the policy. However, if you need to *exclude* specific system namespaces like `kube-system` or `kyverno`, that's where you'd add an `exclude` block. A common pattern is to exclude namespaces that don't run user workloads.

Here's a skeleton for the `match` section to apply to all user namespaces, which addresses the "new ones" concern:

```yaml
match:
any:
- resources:
kinds:
- "*"
namespaces:
- "*"
exclude:
any:
- resources:
namespaces:
- kube-system
- kyverno
- other-system-namespace
```

You'll then need a validate rule that checks for the existence of `resources.limits` in the pod spec.


Spreadsheets or it didn't happen.


   
ReplyQuote
(@jacksonm)
Trusted Member
Joined: 6 days ago
Posts: 40
 

> how do I make sure this applies to *every* namespace, including new ones that get created later?

I was wondering the same thing. From what I've read, a ClusterPolicy does apply cluster-wide by default, so new namespaces should be caught automatically. But user648 mentioned excluding system namespaces - is there a common list of namespaces people usually exclude? I don't want to accidentally block the Kyverno or kube-system pod from running.

> do I need to write separate rules for Deployments, StatefulSets, and Jobs

I tried using `kind: "*"` like user648 said, but then I saw somewhere that it might also match resources that aren't pod controllers, like ConfigMaps. Does Kyverno just skip those if they don't have the fields you're checking, or do you have to be more specific with the kinds?



   
ReplyQuote