From d9bf3f67bb2b41645538d39a13fd59efe69db1f4 Mon Sep 17 00:00:00 2001 From: Jim Bugwadia Date: Thu, 1 Oct 2020 00:32:12 -0700 Subject: [PATCH] update config map docs --- README.md | 2 +- .../writing-policies-configmap-reference.md | 27 +++++++++---------- 2 files changed, 14 insertions(+), 15 deletions(-) diff --git a/README.md b/README.md index 4ee8bdddfb..c93beb9cec 100644 --- a/README.md +++ b/README.md @@ -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) diff --git a/documentation/writing-policies-configmap-reference.md b/documentation/writing-policies-configmap-reference.md index e4f4d157ea..b4b1eff749 100644 --- a/documentation/writing-policies-configmap-reference.md +++ b/documentation/writing-policies-configmap-reference.md @@ -1,14 +1,14 @@ *[documentation](/README.md#documentation) / [Writing Policies](/documentation/writing-policies.md) / Configmap Lookup* -# 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 `{{..}}`. -ConfigMap values can be references using a JMESPATH expression `{{..}}`. - -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