Skip to content

blog: add blog for generating policy#2035

Open
kirti763 wants to merge 1 commit into
kyverno:mainfrom
kirti763:blog/generating-policy
Open

blog: add blog for generating policy#2035
kirti763 wants to merge 1 commit into
kyverno:mainfrom
kirti763:blog/generating-policy

Conversation

@kirti763

Copy link
Copy Markdown

Related issue

This is a blog for kyverno's generating policy.

Proposed Changes

Checklist

  • I have read the contributing guidelines.
  • I have inspected the website preview for accuracy.
  • I have signed off my issue.

Signed-off-by: Kirti Goyal <kg4180553@gmail.com>
@github-actions github-actions Bot added the blog label May 24, 2026

@CortNick CortNick left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kirti763 please have a look at all comments and suggestions. Once you've had a chance to review them, please ping @MariamFahmy98 for a final technical review so we can get this merged asap. Thx!

- General
authors:
- name: Kirti Goyal
excerpt: A practical guide to GeneratingPolicy in Kyverno like automatically creating NetworkPolicies, syncing Secrets, and bootstrapping namespaces without anyone having to remember a checklist

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
excerpt: A practical guide to GeneratingPolicy in Kyverno like automatically creating NetworkPolicies, syncing Secrets, and bootstrapping namespaces without anyone having to remember a checklist
excerpt: A practical guide to GeneratingPolicy in Kyverno. Learn to automatically create NetworkPolicies, sync Secrets, and bootstrap namespaces without having to remember to follow a checklist.


Every Kubernetes platform team has some version of this checklist.

"When you create a new namespace, remember to also create a NetworkPolicy, a

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"When you create a new namespace, remember to also create a NetworkPolicy, a
1. Create a new namespace.
2. Create a NetworkPolicy for the new namespace.
3. Set ResourceQuota and RoleBinding specs.
4. Copy the image pull secret from the default namespace.

Every Kubernetes platform team has some version of this checklist.

"When you create a new namespace, remember to also create a NetworkPolicy, a
ResourceQuota, a RoleBinding, and copy the image pull secret from the default

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
ResourceQuota, a RoleBinding, and copy the image pull secret from the default


"When you create a new namespace, remember to also create a NetworkPolicy, a
ResourceQuota, a RoleBinding, and copy the image pull secret from the default
namespace."

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
namespace."

ResourceQuota, a RoleBinding, and copy the image pull secret from the default
namespace."

It lives in a wiki. Nobody reads the wiki. Someone creates a namespace, forgets three

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
It lives in a wiki. Nobody reads the wiki. Someone creates a namespace, forgets three
Every checklist lives in a wiki. Nobody reads the wiki. Someone creates a namespace, forgets three


Image pull secrets are a constant headache. The secret lives in `default`. Every new
namespace needs a copy of it. Without automation, someone has to manually copy it every time
and then keep it in sync when the secret rotates.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
and then keep it in sync when the secret rotates.
and then keep it in sync when the secret rotates. A GeneratingPolicy can be used to automate this task, reducing drift and ensuring compliance.


With `synchronize: true`, if the source secret is updated, all the copies get updated
too. If the source is deleted, the copies get deleted. The downstream resources stay
in sync with the original automatically.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
in sync with the original automatically.
in sync with the original resources automatically.

too. If the source is deleted, the copies get deleted. The downstream resources stay
in sync with the original automatically.

**Try it:**

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really like these step-by-steps. Did you happen to run all of them to make sure they work @kirti763 ? If so, it might be a good idea to add a few screenshots also.

- expression: generator.Apply(variables.nsName, variables.downstream)
```

In this case, there is one policy. Two resources are created per namespace. You can add more to the list as needed like RoleBindings, ConfigMaps, LimitRanges. The developer creates a namespace and walks away. Everything is already there.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In this case, there is one policy. Two resources are created per namespace. You can add more to the list as needed like RoleBindings, ConfigMaps, LimitRanges. The developer creates a namespace and walks away. Everything is already there.
In this case, there is one policy. Two resources are created per namespace. You can add more to the list as needed like RoleBindings, ConfigMaps, LimitRanges. The developer creates a namespace and continues with their work. GeneratingPolicy ensures that everything is correctly generated for their deployment.

```

When this policy is applied to a cluster with 10 existing namespaces, Kyverno
immediately generates the downstream resources in all 10. Without this, only new

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
immediately generates the downstream resources in all 10. Without this, only new
immediately generates the downstream resources in all 10 namespaces. Without this, only new

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants