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

Add NetworkPolicy example using default-deny rules

    XMLWordPrintable

Details

    • Page
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 2.3.0
    • documentation, operator
    • None
    • 44: Completion 2.3
    • 1

    Description

      Raised by user: https://github.com/couchbase-partners/helm-charts/issues/74

      Increasingly network policies are being used in production deployments with a default deny-all approach, i.e. only approved traffic is allowed. We should have an example showing how to configure this.

      Initially target a deployment with Calico, possibly extend to Cilium and a GKE solution (opt-in).

      Attachments

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

        Activity

          Roo Thorp please verify and close this

          arunkumar Arunkumar Senthilnathan added a comment - Roo Thorp please verify and close this

          Build couchbase-operator-2.3.0-231 contains couchbase-operator commit 0f81b34 with commit message:
          K8S-2510: Add basic network policy information

          build-team Couchbase Build Team added a comment - Build couchbase-operator-2.3.0-231 contains couchbase-operator commit 0f81b34 with commit message: K8S-2510 : Add basic network policy information

          Build couchbase-operator-2.3.0-beta1-112 contains couchbase-operator commit 0f81b34 with commit message:
          K8S-2510: Add basic network policy information

          build-team Couchbase Build Team added a comment - Build couchbase-operator-2.3.0-beta1-112 contains couchbase-operator commit 0f81b34 with commit message: K8S-2510 : Add basic network policy information

          I have a working example here, I've deliberately not included ports to keep it as compatible as possible: https://github.com/patrick-stephens/couchbase-gitops/blob/96254f590bac86b2a0165e0a69b7e5cb1e77d8f1/network-policy-test.sh 

          Ports can be deduced from the server docs as linked from our docs: https://docs.couchbase.com/server/current/install/install-ports.html#detailed-port-description 

          If you start messing with ports then you need to open them all up as required by that version of server and the configuration deployed (if you just open the superset then makes little sense to do it by port). You will also have to start dealing with SDK connections as well to specific ports.

          SDK ingress will need handling but that is out of scope here: it depends on the networking topology deployed if you want to lock it down by CIDR or you could just support any SDK ingress via a 0.0.0.0/0 CIDR (again though bit pointless if the intent is to lock down ports/addresses).

          DAC needs a little handling as well to interact with the K8S API, but then this is pretty standard for any admission controller. Similarly if you want to use `kubectl`, `helm`, etc. from outside the cluster then that also needs to be allowed to access what it needs to - again though a standard network policy issue rather than anything to do with Couchbase.

          Docs have been added along with a tutorial to the 2.3-beta branch so should appear once merged.

          patrick.stephens Patrick Stephens (Inactive) added a comment - - edited I have a working example here, I've deliberately not included ports to keep it as compatible as possible: https://github.com/patrick-stephens/couchbase-gitops/blob/96254f590bac86b2a0165e0a69b7e5cb1e77d8f1/network-policy-test.sh   Ports can be deduced from the server docs as linked from our docs: https://docs.couchbase.com/server/current/install/install-ports.html#detailed-port-description   If you start messing with ports then you need to open them all up as required by that version of server and the configuration deployed (if you just open the superset then makes little sense to do it by port). You will also have to start dealing with SDK connections as well to specific ports. SDK ingress will need handling but that is out of scope here: it depends on the networking topology deployed if you want to lock it down by CIDR or you could just support any SDK ingress via a 0.0.0.0/0 CIDR (again though bit pointless if the intent is to lock down ports/addresses). DAC needs a little handling as well to interact with the K8S API, but then this is pretty standard for any admission controller. Similarly if you want to use `kubectl`, `helm`, etc. from outside the cluster then that also needs to be allowed to access what it needs to - again though a standard network policy issue rather than anything to do with Couchbase. Docs have been added along with a tutorial to the 2.3-beta branch so should appear once merged.
          patrick.stephens Patrick Stephens (Inactive) added a comment - Looks like we'll have to use a CNI with KIND as well, although there are a few options: https://github.com/kubernetes-sigs/kind/issues/842 *  https://github.com/jayunit100/k8sprototypes/blob/master/kind/kind-local-up.sh
          patrick.stephens Patrick Stephens (Inactive) added a comment - Unfortunately targettng a range of ports is only beta in 1.22:  https://kubernetes.io/docs/concepts/services-networking/network-policies/#targeting-a-range-of-ports

          People

            roo.thorp Roo Thorp
            patrick.stephens Patrick Stephens (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes

                PagerDuty