Adding content for CRD NvAdmissionControlSecurityRule/nvshas-9483.

Signed-off-by: Sunil Singh <[email protected]>

docs/05.policy/13.usingcrd/13.usingcrd.md

@@ -29,14 +29,16 @@ CRD's bring many benefits, including:
 
 #### Supported Resource Types
 
-NeuVector supports two kinds of custom resource definitions.  They are the NvSecurityRule and NvClusterSecurityRule.  The difference among the two comes down to the boundary set by the definition of the scope.  The  NvSecurityRule resource is scoped at the namespace level, whereas the NvClusterSecurityRule is scoped at the cluster level.  Either of the resource types can be configured in a yaml file and can be created during deployment, as shown in the deployment instructions and examples for NeuVector.
+NeuVector supports the NvSecurityRule, NvClusterSecurityRule, and NvAdmissionControlSecurityRule custom resource definitions.
 
-The significance of the NvSecurityRule resource type with a scope of namespace lies in the enforcement of the configured domain of the target group, which must match the configured namespace in the NeuVector’s  CRD security policy.  This provides enforcement to prevent unwanted cross-namespace policy creation which affect a Target-Group policy rule.
+The difference between the NvSecurityRule and NvClusterSecurityRule is the boundary set by the definition of the scope. The NvSecurityRule resource is scoped at the namespace level, whereas the NvClusterSecurityRule is scoped at the cluster level. The resource types can be configured in a yaml file and can be created during deployment, as shown in the deployment instructions and examples for NeuVector.
 
-For the NvClusterSecurityRule custom resource definition, this has a cluster level scope, and therefore, does not enforce any namespace boundary on a defined target.  However, the user-context that is used for importing the CRD-yaml file must have the necessary permissions to access or reside in the same namespace as the one configured in the CRD-yaml file, or the import will be rejected.
+The significance of the NvSecurityRule resource type with a scope of namespace lies in the enforcement of the configured domain of the target group, which must match the configured namespace in the NeuVector’s  CRD security policy. This provides enforcement to prevent unwanted cross-namespace policy creation which affect a Target-Group policy rule.
+
+For the NvClusterSecurityRule custom resource definition, this has a cluster level scope, and therefore, does not enforce any namespace boundary on a defined target. However, the user-context that is used for importing the CRD-yaml file must have the necessary permissions to access or reside in the same namespace as the one configured in the CRD-yaml file, or the import will be rejected.
 
 <strong>Enabling CRD Support</strong>
-As described in the Kubernetes and OpenShift deployment sections (Deploying NeuVector),  the appropriate clusterroles and clusterrole bindings for custom resources and NvSecurityRules should be added first.
+As described in the [Kubernetes](../../02.deploying/02.kubernetes/02.kubernetes.md#deploy-neuvector) and [OpenShift](../../02.deploying/04.openshift/04.openshift.md#deploy-on-openshift) deployment sections (Deploying NeuVector),  the appropriate clusterroles and clusterrole bindings for custom resources and NvSecurityRules should be added first.
 
 Then NvSecurityRule and NvClusterSecurityRule should be created using the sample yaml in those sections. NeuVector CRDs can now be deployed.
 
@@ -277,6 +279,42 @@ For example:
 + node-pod.demo is allowed to egress to google.com using SSL
 + Group names such as nv.node-pod.demo are referenced but not defined in the CRD, so are expected to already exist when deployed. See below for defining Groups.
 
+#### Sample NeuVector CRD - NvAdmissionControlSecurityRule
+
+Another method to generate a CRD manifest is from the **Policy > Admission Control** view by clicking the **More Operations** drop-down list and selecting **Export**. Below is a sample NvAdmissionControlSecurityRule CRD manifest:
+
+:::note
+NvAdmissionControlSecurityRule `metadata.name` should always be set to `local` for future extensibility.
+:::
+
+```yaml
+apiVersion: neuvector.com/v1
+kind: NvAdmissionControlSecurityRule
+metadata:
+  creationTimestamp: null
+  name: local
+spec:
+  config:
+    client_mode: service
+    enable: true
+    mode: monitor
+  rules:
+  - action: deny
+    containers:
+    - containers
+    criteria:
+    - name: namespace
+      op: containsAny
+      path: namespace
+      value: n2,ns1
+    disabled: false
+    rule_mode: ""
+```
+
+You can refer to the [complete schema for the CRD](https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.3.0/admission-crd-k8s-1.19.yaml) for modifications to the manifest generated above to meet your requirements.
+
+Once the modifications are done, you can apply the manifest to your Kubernetes cluster.
+
 ### Policy Mode Configuration and Group Definition
 
 Policy mode configuration and Group definition is supported within the CRD configuration yaml file.  With policymode configured in the yaml configuration file, importing such file will set the target group to this value for the CRD import.  

versioned_docs/version-5.4/05.policy/13.usingcrd/13.usingcrd.md

@@ -29,11 +29,13 @@ CRD's bring many benefits, including:
 
 #### Supported Resource Types
 
-NeuVector supports two kinds of custom resource definitions.  They are the NvSecurityRule and NvClusterSecurityRule.  The difference among the two comes down to the boundary set by the definition of the scope.  The  NvSecurityRule resource is scoped at the namespace level, whereas the NvClusterSecurityRule is scoped at the cluster level.  Either of the resource types can be configured in a yaml file and can be created during deployment, as shown in the deployment instructions and examples for NeuVector.
+NeuVector supports the NvSecurityRule, NvClusterSecurityRule, and NvAdmissionControlSecurityRule custom resource definitions.
 
-The significance of the NvSecurityRule resource type with a scope of namespace lies in the enforcement of the configured domain of the target group, which must match the configured namespace in the NeuVector’s  CRD security policy.  This provides enforcement to prevent unwanted cross-namespace policy creation which affect a Target-Group policy rule.
+The difference between the NvSecurityRule and NvClusterSecurityRule is the boundary set by the definition of the scope. The NvSecurityRule resource is scoped at the namespace level, whereas the NvClusterSecurityRule is scoped at the cluster level. The resource types can be configured in a yaml file and can be created during deployment, as shown in the deployment instructions and examples for NeuVector.
 
-For the NvClusterSecurityRule custom resource definition, this has a cluster level scope, and therefore, does not enforce any namespace boundary on a defined target.  However, the user-context that is used for importing the CRD-yaml file must have the necessary permissions to access or reside in the same namespace as the one configured in the CRD-yaml file, or the import will be rejected.
+The significance of the NvSecurityRule resource type with a scope of namespace lies in the enforcement of the configured domain of the target group, which must match the configured namespace in the NeuVector’s  CRD security policy. This provides enforcement to prevent unwanted cross-namespace policy creation which affect a Target-Group policy rule.
+
+For the NvClusterSecurityRule custom resource definition, this has a cluster level scope, and therefore, does not enforce any namespace boundary on a defined target. However, the user-context that is used for importing the CRD-yaml file must have the necessary permissions to access or reside in the same namespace as the one configured in the CRD-yaml file, or the import will be rejected.
 
 <strong>Enabling CRD Support</strong>
 As described in the [Kubernetes](../../02.deploying/02.kubernetes/02.kubernetes.md#deploy-neuvector) and [OpenShift](../../02.deploying/04.openshift/04.openshift.md#deploy-on-openshift) deployment sections (Deploying NeuVector),  the appropriate clusterroles and clusterrole bindings for custom resources and NvSecurityRules should be added first.
@@ -277,6 +279,42 @@ For example:
 + node-pod.demo is allowed to egress to google.com using SSL
 + Group names such as nv.node-pod.demo are referenced but not defined in the CRD, so are expected to already exist when deployed. See below for defining Groups.
 
+#### Sample NeuVector CRD - NvAdmissionControlSecurityRule
+
+Another method to generate a CRD manifest is from the **Policy > Admission Control** view by clicking the **More Operations** drop-down list and selecting **Export**. Below is a sample NvAdmissionControlSecurityRule CRD manifest:
+
+:::note
+NvAdmissionControlSecurityRule `metadata.name` should always be set to `local` for future extensibility.
+:::
+
+```yaml
+apiVersion: neuvector.com/v1
+kind: NvAdmissionControlSecurityRule
+metadata:
+  creationTimestamp: null
+  name: local
+spec:
+  config:
+    client_mode: service
+    enable: true
+    mode: monitor
+  rules:
+  - action: deny
+    containers:
+    - containers
+    criteria:
+    - name: namespace
+      op: containsAny
+      path: namespace
+      value: n2,ns1
+    disabled: false
+    rule_mode: ""
+```
+
+You can refer to the [complete schema for the CRD](https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.3.0/admission-crd-k8s-1.19.yaml) for modifications to the manifest generated above to meet your requirements.
+
+Once the modifications are done, you can apply the manifest to your Kubernetes cluster.
+
 ### Policy Mode Configuration and Group Definition
 
 Policy mode configuration and Group definition is supported within the CRD configuration yaml file.  With policymode configured in the yaml configuration file, importing such file will set the target group to this value for the CRD import.