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

Test Needs runAsUser Randomization

    XMLWordPrintable

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • not-targeted
    • testing
    • None
    • 46: Completion 2.3. bk maint, 15: Blogs, future fixes, autom, 17: Automation, future fixes, 21: Auto., crackn' on Krakken, 23: ARM, Trackin' Kraken, 25: Maintain, 28: Upgrades, small fixes, 30: Maintenance, CMOS, ARM, 31: Get Crackin on Kraken
    • 1

    Description

      Having this hard coded as 1000 is just far too dangerous.  For a start a lot of images out there assume a UID of 1000 ("couchbase" default).  Problem is, if you forget to add the pod security context to something and also run as a different user, things will break.

      Attachments

        Issue Links

          For Gerrit Dashboard: K8S-2517
          # Subject Branch Project Status CR V

          Activity

            roo.thorp Roo Thorp added a comment -

            Simon Murray I've tried simply picking a random number where we apply the security context, but CB server pods immediately fail with:
            whoami: cannot find name for user ID 6481
            The docs suggest that if we are running as non-root, we must set runAsUser to 1000; does that not conflict with this change?

            roo.thorp Roo Thorp added a comment - Simon Murray I've tried simply picking a random number where we apply the security context, but CB server pods immediately fail with: whoami: cannot find name for user ID 6481 The docs suggest that if we are running as non-root, we must set runAsUser to 1000; does that not conflict with this change?

            Don't think this is valid since Couchbase only recognizes non-root user of 1000.  Otherwise you'd have to use uid=0.  Anything else fails.  This section of docs is to highlight fsGroup that user should belong to for Persistent Volumes.

             

            Regarding backup, apparently this process can run as different.  Perhaps then backup should have its own security context. 

            tommie Tommie McAfee added a comment - Don't think this is valid since Couchbase only recognizes non-root user of 1000.  Otherwise you'd have to use uid=0.  Anything else fails.  This section of docs is to highlight fsGroup that user should belong to for Persistent Volumes.   Regarding backup, apparently this process can run as different.  Perhaps then backup should have its own security context. 
            ingenthr Matt Ingenthron added a comment - - edited

            Per constraints, new definition of done is that we use this only for backup and not for Couchbase server pod. Also, note we cannot do this with fluentbit, as the sidecar needs to be able to share the volume mount.

            ingenthr Matt Ingenthron added a comment - - edited Per constraints, new definition of done is that we use this only for backup and not for Couchbase server pod. Also, note we cannot do this with fluentbit, as the sidecar needs to be able to share the volume mount.

            Per review, may be able to push this one out.

            ingenthr Matt Ingenthron added a comment - Per review, may be able to push this one out.

            People

              gilad.kalchheim Gilad Kalchheim
              simon.murray Simon Murray
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty