mirrors/kyverno
1
0
Fork 0
mirror of https://github.com/kyverno/kyverno.git synced 2024-12-14 11:57:48 +00:00
Code Activity

Merge pull request #1163 from nirmata/improvement/update_configmap_docs

Browse source 
update config map docs
This commit is contained in:
Jim Bugwadia 2020-10-01 07:15:20 -07:00 committed by GitHub
commit f35e6893e9
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 14 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -113,7 +113,7 @@ See [docs](https://github.com/nirmata/kyverno/#documentation) for complete detai
- [Preconditions](documentation/writing-policies-preconditions.md)
- [Auto-Generation of Pod Controller Policies](documentation/writing-policies-autogen.md)
- [Background Processing](documentation/writing-policies-background.md)
- [Configmap Lookup](documentation/writing-policies-configmap-reference.md)
- [Using ConfigMaps for variables](documentation/writing-policies-configmap-reference.md)
- [Testing Policies](documentation/testing-policies.md)
- [Policy Violations](documentation/policy-violations.md)
- [Kyverno CLI](documentation/kyverno-cli.md)

27
documentation/writing-policies-configmap-reference.md
View file

@ -1,14 +1,14 @@
<small>*[documentation](/README.md#documentation) / [Writing Policies](/documentation/writing-policies.md) / Configmap Lookup*</small>
# Configmap Reference in Kyverno Policy
# Using ConfigMaps for Variables
There are many cases where the values that are passed into kyverno policies are dynamic, In such a cases the values are added/ modified inside policy itself.
There are many cases where the values that are passed into Kyverno policies are dynamic or need to be vary based on the execution environment.
The Configmap Reference allows the reference of configmap values inside kyverno policy rules as a JMESPATH, So for any required changes in the values of a policy, a modification has to be done on the referred configmap.
Kyverno supports using Kubernetes [ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/) to manage variable values outside of a policy definition.
# Defining Rule Context
# Defining ConfigMaps in a Rule Context
To reference values from a ConfigMap inside any Rule, define a context inside the rule with one or more ConfigMap declarations.
To refer to values from a ConfigMap inside any Rule, define a context inside the rule with one or more ConfigMap declarations.
````yaml
rules:
@ -24,7 +24,7 @@ To reference values from a ConfigMap inside any Rule, define a context inside th
namespace: test
````
Referenced Configmap Definition
Sample ConfigMap Definition
````yaml
apiVersion: v1
@ -35,21 +35,20 @@ metadata:
name: mycmap
````
# Referring Value
# Looking up values
A ConfigMap that is defined inside the rule context can be referred to using its unique name within the context.
A ConfigMap that is defined in a rule context can be referred to using its unique name within the context. ConfigMap values can be referenced using a JMESPATH style expression `{{<name>.<data>.<key>}}`.
ConfigMap values can be references using a JMESPATH expression `{{<name>.<data>.<key>}}`.
For the example above, we can refer to a ConfigMap value using {{dictionary.data.env}}. The variable will be substituted with production during policy execution.
For the example above, we can refer to a ConfigMap value using `{{dictionary.data.env}}`. The variable will be substituted with the value `production` during policy execution.
# Handling Array Values
The ConfigMap value can be an array of string values in JSON format. Kyverno will parse the JSON string to a list of strings, so set operations like In and NotIn can then be applied.
For example, a list of allowed roles can be stored in a ConfigMap, and the Kyverno policy can refer to this list to deny the requests where the role does not match the one of the values in the list.
For example, a list of allowed roles can be stored in a ConfigMap, and the Kyverno policy can refer to this list to deny the requests where the role does not match one of the values in the list.
Here are the allowed roles in the ConfigMap:
Here are the allowed roles in the ConfigMap
````yaml
apiVersion: v1
data:
@ -60,8 +59,8 @@ metadata:
namespace: test
````
Here is a rule to block a Deployment if the value of annotation `role` is not in the allowed list:
This is a rule to deny the Deployment operation, if the value of annotation `role` is not in the allowed list:
````yaml
spec:
validationFailureAction: enforce