Details
-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
1
Description
From https://docs.couchbase.com/operator/current/concept-operator.html#dynamic-admission-controller
it is said :
Dynamic Admission Controller Security Models
|
|
|
The recommended — and default — deployment model is to run a single instance of the DAC per Kubernetes cluster. The DAC is backward compatible with all previous CRD versions, therefore you only need to deploy the most recent version, regardless of the Operator versions running on the platform. |
|
|
The DAC may also be deployed at the namespace scope for more security conscious environments. This limits the DAC so that it is only able to see Kubernetes resources within the namespace in which it is deployed, for example secrets. With this security model, one instance of the DAC is required per namespace in which the Operator is deployed. In the following DAC architecture section, when running the DAC namespaced, ClusterRoles and ClusterRoleBindings are replaced with Roles and RoleBindings respectively. |
|
|
Regardless of chosen security model, the DAC will require cluster administrator privileges to deploy. The roles and role bindings require privilege escalation. Additionally the mutating and validating webhooks affect the Kubernetes API, so must be installed by an administrator.
|
Can you confirm the 2nd section "The DAC may also be deployed at the namespace scope for more security conscious environments." is valid?
We did some test with Kering and, deploying the AO and DAC on multiple namespaces using Helm Chart, we DID see in the AO logs of namespace A that is was using DAC instance of namespace B.
In our case, the statement :
This limits the DAC so that it is only able to see Kubernetes resources within the namespace in which it is deployed, for example secrets. |
was not true.
Attachments
Issue Links
- relates to
-
K8S-2310 Helm only deploy DAC once clarification
-
- Closed
-