Convert ConfigMaps in CRD to allow dynamic update of parameters
Description
As per customer request:
When using per namespace VIPs it is not possible to add these dynamically to CIS because it is need to be add them to both ConfigMap and the –namespace command-line and hence a CIS restart. This CIS restart is not a desired behaviour because every time it is updated it would cause an alarm in operations.
The use of namespace-label is not feasible because it is required that namespace’s tenants have their own ConfigMaps/Policy. The customer is happy with this namespace-label behaviour in which namespace-label matching namespaces cannot have their own ConfigMap/Policy.
Ultimately the customer would like to be able to add VIPs and any other day-to-day change without requiring a CIS restart. Because of this and because of schema validation the customer would like to see the ConfigMap to be transformed into a CRD.
Actual Problem
ConfigMaps are not validated by Kubernetes.
It is required the restart of CIS in day-to-day operations which is suboptimal. Every time there is a CIS restart Operations is required to validate that the restart is legitimate and not a failure before clearing the alarm.
Solution Proposed
Transform the ConfigMap into a CRD and allow adding new VIPs/namespaces without having to edit the CIS Deployment file which is required at present.
Title
Convert ConfigMaps in CRD to allow dynamic update of parameters
Description
As per customer request:
When using per namespace VIPs it is not possible to add these dynamically to CIS because it is need to be add them to both ConfigMap and the –namespace command-line and hence a CIS restart. This CIS restart is not a desired behaviour because every time it is updated it would cause an alarm in operations.
The use of namespace-label is not feasible because it is required that namespace’s tenants have their own ConfigMaps/Policy. The customer is happy with this namespace-label behaviour in which namespace-label matching namespaces cannot have their own ConfigMap/Policy.
Ultimately the customer would like to be able to add VIPs and any other day-to-day change without requiring a CIS restart. Because of this and because of schema validation the customer would like to see the ConfigMap to be transformed into a CRD.
Actual Problem
ConfigMaps are not validated by Kubernetes.
It is required the restart of CIS in day-to-day operations which is suboptimal. Every time there is a CIS restart Operations is required to validate that the restart is legitimate and not a failure before clearing the alarm.
Solution Proposed
Transform the ConfigMap into a CRD and allow adding new VIPs/namespaces without having to edit the CIS Deployment file which is required at present.
Alternatives
Additional context