Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restrict volume types #32

Closed
ssvinarev opened this issue Apr 1, 2021 · 2 comments
Closed

Restrict volume types #32

ssvinarev opened this issue Apr 1, 2021 · 2 comments

Comments

@ssvinarev
Copy link

Hi!

In this example:
https://github.com/kyverno/policies/blob/main/pod-security/restricted/restrict-volume-types/restrict-volume-types.yaml
a huge list of NOT allowed volume types described.

I'm stuck trying to describe a list of ONLY allowed volume types using available anchors and operators of kyverno.
I need to write a rule that reads like:
"If a volume is defined then the type of it can ONLY be configMap or emptyDir or persistentVolumeClaim or ..."
This makes rule definition shorter and prevents of not wanted allow of newly added types in future.

Can anyone help?

@JimBugwadia
Copy link
Member

Hi @ssvinarev - since the volume type is an object, this may be a bit tricky to do using an include / allow list.

Have you tried using an anyPattern and to define the types of volumes you want to allow.

      pattern:
        - spec:
          (volumes):
          - configMap : 
        - spec:
          (volumes):
          - emptyDir: 
        - spec:
          (volumes):
          - persistentVolumeClaim: 

https://kyverno.io/docs/writing-policies/validate/#anypattern---logical-or-across-multiple-validation-patterns

@chipzoller
Copy link
Member

Hi @ssvinarev I think Jim's suggestion is a good approach and so I'm going to close this issue. If you still need help with adapting either one of these, please either re-open or come see us in the #kyverno Kubernetes Slack channel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants