mirror of
https://github.com/kyverno/kyverno.git
synced 2025-03-05 07:26:55 +00:00
Bugfix/update docs for deny rules (#886)
* - support wildcards for namespaces * do not annotate resource, unless policy is an autogen policy * close HTTP body * improve messages * - update docs for deny rules - add presentations and videos to README.md
This commit is contained in:
Jim Bugwadia
GitHub
parent
c48627595e
commit
d4e5790a66
4 changed files with 99 additions and 18 deletions
53
README.md
53
README.md
|
|
@ -49,8 +49,9 @@ spec:
|
|||
- name: "*"
|
||||
resources:
|
||||
limits:
|
||||
# '?' requires 1 alphanumeric character and '*' means that there can be 0 or more characters.
|
||||
# Using them together e.g. '?*' requires at least one character.
|
||||
# '?' requires 1 alphanumeric character and '*' means that
|
||||
# there can be 0 or more characters. Using them together
|
||||
# e.g. '?*' requires at least one character.
|
||||
memory: "?*"
|
||||
cpu: "?*"
|
||||
requests:
|
||||
|
|
@ -58,6 +59,33 @@ spec:
|
|||
cpu: "?*"
|
||||
```
|
||||
|
||||
This policy prevents users from changing default network policies:
|
||||
|
||||
```yaml
|
||||
apiVersion: kyverno.io/v1
|
||||
kind: ClusterPolicy
|
||||
metadata:
|
||||
name: deny-netpol-changes
|
||||
spec:
|
||||
validationFailureAction: enforce
|
||||
background: false
|
||||
rules:
|
||||
- name: check-netpol-updates
|
||||
match:
|
||||
resources:
|
||||
kinds:
|
||||
- NetworkPolicy
|
||||
name:
|
||||
- *-default
|
||||
exclude:
|
||||
clusterRoles:
|
||||
- cluster-admin
|
||||
validate:
|
||||
message: "Changing default network policies is not allowed"
|
||||
deny: {}
|
||||
```
|
||||
|
||||
|
||||
### 2. Mutating resources
|
||||
|
||||
This policy sets the imagePullPolicy to Always if the image tag is latest:
|
||||
|
|
@ -112,18 +140,16 @@ spec:
|
|||
KAFKA_ADDRESS: "192.168.10.13:9092,192.168.10.14:9092,192.168.10.15:9092"
|
||||
```
|
||||
|
||||
### 4. More examples
|
||||
|
||||
Refer to a list of curated of **_[sample policies](/samples/README.md)_** that can be applied to your cluster.
|
||||
**For more examples, refer to a list of curated of **_[sample policies](/samples/README.md)_** that can be applied to your cluster.**
|
||||
|
||||
## Documentation
|
||||
|
||||
- [Getting Started](documentation/installation.md)
|
||||
- [Writing Policies](documentation/writing-policies.md)
|
||||
- [Selecting Resources](/documentation/writing-policies-match-exclude.md)
|
||||
- [Validate Resources](documentation/writing-policies-validate.md)
|
||||
- [Mutate Resources](documentation/writing-policies-mutate.md)
|
||||
- [Generate Resources](documentation/writing-policies-generate.md)
|
||||
- [Validating Resources](documentation/writing-policies-validate.md)
|
||||
- [Mutating Resources](documentation/writing-policies-mutate.md)
|
||||
- [Generating Resources](documentation/writing-policies-generate.md)
|
||||
- [Variable Substitution](documentation/writing-policies-variables.md)
|
||||
- [Preconditions](documentation/writing-policies-preconditions.md)
|
||||
- [Auto-Generation of Pod Controller Policies](documentation/writing-policies-autogen.md)
|
||||
|
|
@ -133,6 +159,17 @@ Refer to a list of curated of **_[sample policies](/samples/README.md)_** that c
|
|||
- [Kyverno CLI](documentation/kyverno-cli.md)
|
||||
- [Sample Policies](/samples/README.md)
|
||||
|
||||
|
||||
## Presentations and Articles
|
||||
|
||||
- [Introducing Kyverno - blog post](https://nirmata.com/2019/07/11/managing-kubernetes-configuration-with-policies/)
|
||||
- [CNCF Video and Slides](https://www.cncf.io/webinars/how-to-keep-your-clusters-safe-and-healthy/)
|
||||
- [10 Kubernetes Best Practices - blog post](https://thenewstack.io/10-kubernetes-best-practices-you-can-easily-apply-to-your-clusters/)
|
||||
- [VMware Code Meetup Video](https://www.youtube.com/watch?v=mgEmTvLytb0)
|
||||
- [Virtual Rejekts Video](https://www.youtube.com/watch?v=caFMtSg4A6I)
|
||||
- [TGIK Video](https://www.youtube.com/watch?v=ZE4Zu9WQET4&list=PL7bmigfV0EqQzxcNpmcdTJ9eFRPBe-iZa&index=18&t=0s)
|
||||
|
||||
|
||||
## License
|
||||
|
||||
[Apache License 2.0](https://github.com/nirmata/kyverno/blob/master/LICENSE)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
<small>*[documentation](/README.md#documentation) / [Writing Policies](/documentation/writing-policies.md) / Generate Resources*</small>
|
||||
|
||||
# Generate Resources
|
||||
# Generating Resources
|
||||
|
||||
The ```generate``` rule can used to create additional resources when a new resource is created. This is useful to create supporting resources, such as new role bindings for a new namespace.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
<small>*[documentation](/README.md#documentation) / [Writing Policies](/documentation/writing-policies.md) / Mutate Resources*</small>
|
||||
|
||||
# Mutate Resources
|
||||
# Mutating Resources
|
||||
|
||||
The ```mutate``` rule can be used to add, replace, or delete elements in matching resources. A mutate rule can be written as a JSON Patch or as an overlay.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,15 @@
|
|||
<small>*[documentation](/README.md#documentation) / [Writing Policies](/documentation/writing-policies.md) / Validate Resources*</small>
|
||||
|
||||
|
||||
# Validate Resources
|
||||
# Validating Resources and Requests
|
||||
|
||||
A validation rule is expressed as an overlay pattern that expresses the desired configuration. Resource configurations must match fields and expressions defined in the pattern to pass the validation rule. The following rules are followed when processing the overlay pattern:
|
||||
A validation rule can be used to validate resources or to deny API requests based on other information.
|
||||
|
||||
To validate resource data, define a [pattern](#patterns) in the validation rule. To deny certain API requests define a [deny](#deny-rules) element in the validation rule along a set of conditions that control when to allow or deny the request.
|
||||
|
||||
## Patterns
|
||||
|
||||
A validation rule that checks resource data is defined as an overlay pattern that provides the desired configuration. Resource configurations must match fields and expressions defined in the pattern to pass the validation rule. The following rules are followed when processing the overlay pattern:
|
||||
|
||||
1. Validation will fail if a field is defined in the pattern and if the field does not exist in the configuration.
|
||||
2. Undefined fields are treated as wildcards.
|
||||
|
|
@ -14,7 +20,6 @@ A validation rule is expressed as an overlay pattern that expresses the desired
|
|||
7. The validation of siblings is performed only when one of the field values matches the value defined in the pattern. You can use the parenthesis operator to explictly specify a field value that must be matched. This allows writing rules like 'if fieldA equals X, then fieldB must equal Y'.
|
||||
8. Validation of child values is only performed if the parent matches the pattern.
|
||||
|
||||
## Patterns
|
||||
|
||||
### Wildcards
|
||||
1. `*` - matches zero or more alphanumeric characters
|
||||
|
|
@ -33,7 +38,7 @@ A validation rule is expressed as an overlay pattern that expresses the desired
|
|||
|
||||
There is no operator for `equals` as providing a field value in the pattern requires equality to the value.
|
||||
|
||||
## Anchors
|
||||
### Anchors
|
||||
|
||||
Anchors allow conditional processing (i.e. "if-then-else) and other logical checks in validation patterns. The following types of anchors are supported:
|
||||
|
||||
|
|
@ -45,7 +50,7 @@ Anchors allow conditional processing (i.e. "if-then-else) and other logical chec
|
|||
| Existence | ^() | Works on the list/array type only. If at least one element in the list satisfies the pattern. In contrast, a conditional anchor would validate that all elements in the list match the pattern. <br/>e.g. At least one container with image nginx:latest must exist. <br/> ^(containers):<br/> - image: nginx:latest<br/> |
|
||||
| Negation | X() | The tag cannot be specified. The value of the tag is not evaulated. <br/>e.g. Hostpath tag cannot be defined.<br/> X(hostPath):<br/> |
|
||||
|
||||
## Anchors and child elements
|
||||
### Anchors and child elements
|
||||
|
||||
Child elements are handled differently for conditional and equality anchors.
|
||||
|
||||
|
|
@ -77,7 +82,7 @@ For equality anchors, a child element is considered to be part of the "then" cla
|
|||
This is read as "If a hostPath volume exists, then the path must not be equal to /var/run/docker.sock".
|
||||
|
||||
|
||||
## Examples
|
||||
### Validation Pattern Examples
|
||||
|
||||
The following rule prevents the creation of Deployment, StatefuleSet and DaemonSet resources without label 'app' in selector:
|
||||
|
||||
|
|
@ -113,7 +118,7 @@ spec:
|
|||
|
||||
````
|
||||
|
||||
### Existence anchor: at least one
|
||||
#### Existence anchor: at least one
|
||||
|
||||
A variation of an anchor, is to check that in a list of elements at least one element exists that matches the patterm. This is done by using the ^(...) notation for the field.
|
||||
|
||||
|
|
@ -147,7 +152,7 @@ spec:
|
|||
memory: "2048Mi"
|
||||
````
|
||||
|
||||
### Logical OR across validation patterns
|
||||
#### Logical OR across validation patterns
|
||||
|
||||
In some cases content can be defined at a different level. For example, a security context can be defined at the Pod or Container level. The validation rule should pass if either one of the conditions is met.
|
||||
|
||||
|
|
@ -190,5 +195,44 @@ Additional examples are available in [samples](/samples/README.md)
|
|||
|
||||
The `validationFailureAction` attribute controls processing behaviors when the resource is not compliant with the policy. If the value is set to `enforce` resource creation or updates are blocked when the resource does not comply, and when the value is set to `audit` a policy violation is reported but the resource creation or update is allowed.
|
||||
|
||||
## Deny rules
|
||||
|
||||
In addition to applying patterns to check resources, a validate rule can `deny` a request based on a set of conditions. This is useful for applying fine grained access controls that cannot be performed using Kubernetes RBAC.
|
||||
|
||||
For example, the policy below denies `delete requests` for objects with the label `app.kubernetes.io/managed-by: kyverno` and for all users who do not have the `cluster-admin` role.
|
||||
|
||||
As the example shows, you can use `match` and `exclude` to select when the rule should be applied and then use additional conditions in the `deny` declaration to apply fine-grained controls.
|
||||
|
||||
Note that the `validationFailureAction` must be set to `enforce` to block the request.
|
||||
|
||||
```yaml
|
||||
apiVersion: kyverno.io/v1
|
||||
kind: ClusterPolicy
|
||||
metadata:
|
||||
name: multi-tenancy
|
||||
spec:
|
||||
validationFailureAction: enforce
|
||||
background: false
|
||||
rules:
|
||||
- name: block-deletes-for-kyverno-resources
|
||||
match:
|
||||
resources:
|
||||
selector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/managed-by: kyverno
|
||||
exclude:
|
||||
clusterRoles:
|
||||
- cluster-admin
|
||||
validate:
|
||||
message: "Deleting {{request.oldObject.kind}}/{{request.oldObject.metadata.name}} is not allowed"
|
||||
deny:
|
||||
conditions:
|
||||
- key: "{{request.operation}}"
|
||||
operator: Equals
|
||||
value: "DELETE"
|
||||
```
|
||||
|
||||
Learn more about using [variables](writing-policies-variables.md) and [conditions](writing-policies-preconditions.md) in upcoming sections.
|
||||
|
||||
---
|
||||
<small>*Read Next >> [Mutate Resources](/documentation/writing-policies-mutate.md)*</small>
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue