Uploaded image for project: 'Couchbase Kubernetes'
  1. Couchbase Kubernetes
  2. K8S-2314

Confirm the DAC only applies to resources linked to a given namespace

    XMLWordPrintable

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • None
    • helm
    • 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

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            yes, I think we should Raju Suravarjjala

            ingenthr Matt Ingenthron added a comment - yes, I think we should Raju Suravarjjala
            simon.murray Simon Murray added a comment -

            It is a perfectly valid and correct statement.  If you deploy with

            cbopcfg create admission --scope=namespace --namespace-selector=key=value

            then it will generated scoped webhooks.

            Problem is that Helm doesn't support this, so every time you deploy the DAC it will create a cluster scoped one, and thus every couchbase.com/v2 API request will get routed to every verison of the DAC that exists on the platform.

            simon.murray Simon Murray added a comment - It is a perfectly valid and correct statement.  If you deploy with cbopcfg create admission --scope=namespace --namespace-selector=key=value then it will generated scoped webhooks. Problem is that Helm doesn't support this, so every time you deploy the DAC it will create a cluster scoped one, and thus every couchbase.com/v2 API request will get routed to every verison of the DAC that exists on the platform.

            People

              ingenthr Matt Ingenthron
              fabrice.leray Fabrice Leray
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty