Does issue with MustRunAsNonRoot and USER <user> apply to Windows?

[jromero]

Summary

We need to investigate if the following issue for linux on k8s applies to Windows.

Details

Multiple users have reported an issue with the use of USER <user>.

Issue: #44

From slack:

We are trying to test our deployment against the suggested PodSecurityPolicy in k8s. K8s states the following:

MustRunAsNonRoot - Requires that the pod be submitted with a non-zero runAsUser or have the USER directive defined (using a numeric UID) in the image. Pods which have specified neither runAsNonRoot nor runAsUser settings will be mutated to set runAsNonRoot=true, thus requiring a defined non-zero numeric USER directive in the container. No default provided. Setting allowPrivilegeEscalation=false is strongly recommended with this strategy.

The Docker docs say:

USER <user>[:<group>] or
USER <UID>[:<GID>]

The following PR addresses this issue for sample linux stacks: #58

At an initial glance the solution applied to linux doesn't seem to translate directly to Windows due to the fact that UID and GID are unknown and can't be preset when creating a user. (This information was provided by @micahyoung)

Acceptance

1. It is determined whether this issue applies to Windows or not.
2. If it does, a proposed solution is provided.

[micahyoung]

Late update, sorry. After some earlier digging and testing, it appears k8s for Windows has a windows-specific method of specifying a container run-as user which according to testing, is compatible with our current method of applying non-root ownership to files for Windows images.

apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-pod-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["ping", "-t", "localhost"]
  nodeSelector:
    kubernetes.io/os: windows

Source: https://kubernetes.io/docs/tasks/configure-pod-container/configure-runasusername/

Initially, Windows-builders, generated by pack, would not work with non-ContainerAdministrator users on k8s using the builder as the container image. But since this set of changes to imgutil, the builders and lifecycle operations appear to work fine, as shown in this test job example, run against a GKE 1.16.11 with a WINDOWS_LTSC node pool, using the latest sample cnbs/sample-builder:nanoserver-1809 builder.

job.yml

apiVersion: batch/v1
kind: Job
metadata:
  name: buildpacks-lifecycle-windows
spec:
  backoffLimit: 0
  template:
    spec:
      securityContext:
        windowsOptions:
          runAsUserName: "ContainerUser"
      nodeSelector:
        kubernetes.io/os: windows
      containers:
        - name: all-phases
          image: "cnbs/sample-builder:nanoserver-1809"
          env:
            - name: APP_IMAGE
              value: "<gcr repo image>"
          command: ["cmd", "/s", "/c"]
          args:
            - '
              ping 127.0.0.1 -n 5 > nul &&
              set HELPER_DIR=C:\Users\ContainerUser&&
              set PATH=%PATH%;C:\Users\ContainerUser&&
              curl -L https://github.com/GoogleCloudPlatform/docker-credential-gcr/releases/download/v2.0.1/docker-credential-gcr_windows_amd64-2.0.1.tar.gz -o dcg.tar.gz && tar -xzf dcg.tar.gz docker-credential-gcr.exe && call move docker-credential-gcr.exe %HELPER_DIR%\docker-credential-gcr.exe && del dcg.tar.gz &&
              docker-credential-gcr configure-docker --registries=gcr.io &&
              set DEBUG=debug&&
              set CACHE_DIR=c:\cache&&
              call mkdir %CACHE_DIR% &&
              call c:\cnb\lifecycle\detector.exe -group=c:\layers\group.toml -app=c:\workspace -plan=c:\layers\plan.toml -log-level=%DEBUG% &&
              call c:\cnb\lifecycle\analyzer.exe -group=c:\layers\group.toml -layers=c:\layers -cache-dir=%CACHE_DIR% -log-level=%DEBUG% %APP_IMAGE% &&
              call c:\cnb\lifecycle\restorer.exe -group=c:\layers\group.toml -layers=c:\layers -cache-dir=%CACHE_DIR% -log-level=%DEBUG% &&
              call c:\cnb\lifecycle\builder.exe  -group=c:\layers\group.toml -layers=c:\layers -app=c:\workspace -plan=c:\layers\plan.toml &&
              call c:\cnb\lifecycle\exporter.exe -group=c:\layers\group.toml -layers=c:\layers -app=c:\workspace -cache-dir=%CACHE_DIR% -log-level=%DEBUG% %APP_IMAGE% &&
              echo done
              '

      restartPolicy: Never

Output

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   659  100   659    0     0    659      0  0:00:01 --:--:--  0:00:01  2345
100 2406k  100 2406k    0     0  2406k      0  0:00:01 --:--:--  0:00:01 2406k
        1 file(s) moved.
C:\Users\ContainerUser\.docker\config.json configured to use this credential helper for GCR registries
======== Results ========
pass: samples/hello-world-windows@0.0.1
Resolving plan... (try #1)
samples/hello-world-windows 0.0.1
Analyzing image "<REDACTED>@sha256:63a5ba944da9cf92290b820b195e70a8d660aaed04824b1f769bba74948c274b"
--- Hello World buildpack
     env_dir: c:\platform\env
     env_vars:
       CNB_STACK_ID=io.buildpacks.samples.stacks.nanoserver-1809
       COMSPEC=C:\Windows\system32\cmd.exe
       env_dir=c:\platform\env
       layers_dir=c:\layers\samples_hello-world-windows
       PATH=c:\Windows\system32;C:\Windows;C:\Users\ContainerUser
       CNB_BUILDPACK_DIR=c:\cnb\buildpacks\samples_hello-world-windows\0.0.1
       PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS;.MSC
       plan_path=C:\Windows\TEMP\plan.727239687\samples_hello-world-windows\plan.toml
       PROMPT=$P$G
       SYSTEMROOT=C:\Windows
     layers_dir: c:\layers\samples_hello-world-windows
     plan_path: C:\Windows\TEMP\plan.727239687\samples_hello-world-windows\plan.toml
     plan contents:
       [[entries]]
       name = "some-world"
--- Done
no project metadata found at path 'project-metadata.toml', project metadata will not be exported
Reusing layers from image '<REDACTED>@sha256:63a5ba944da9cf92290b820b195e70a8d660aaed04824b1f769bba74948c274b'
Layer 'slice-1' SHA: sha256:96b9acbbce684daf9fae3d4670917ddee3bc7693109761f7e7be01616fb13a25
Adding 1/1 app layer(s)
Reusing tarball for layer "launcher" with SHA: sha256:f35e9eec3a1ca69161ccdd1296351ba89a2c1a703cb944db9d4bd4bca00eaa25
Adding layer 'launcher'
Layer 'launcher' SHA: sha256:f35e9eec3a1ca69161ccdd1296351ba89a2c1a703cb944db9d4bd4bca00eaa25
Reusing tarball for layer "config" with SHA: sha256:7fe9e383b54bfdfed6bfa5e0719edb8c370a5873a937059ee0b2996d00bf9512
Adding layer 'config'
Layer 'config' SHA: sha256:7fe9e383b54bfdfed6bfa5e0719edb8c370a5873a937059ee0b2996d00bf9512
Adding label 'io.buildpacks.lifecycle.metadata'
Adding label 'io.buildpacks.build.metadata'
Adding label 'io.buildpacks.project.metadata'
Setting CNB_LAYERS_DIR=c:\layers
Setting CNB_APP_DIR=c:\workspace
Setting CNB_PLATFORM_API=0.3
Setting CNB_DEPRECATION_MODE=quiet
Setting ENTRYPOINT: 'c:\cnb\lifecycle\launcher.exe'
*** Images (sha256:fd9a7d38ce459974864fec7e0fbf222862178489f149b5f736c489468ae74edb):
      <REDACTED>

*** Digest: sha256:fd9a7d38ce459974864fec7e0fbf222862178489f149b5f736c489468ae74edb
done 

[micahyoung]

Currently, the non-"root" (or non-Administrator) permissions added by imgutil for Windows image files and directories are Owner/Group = BUILTIN\Users which is sufficient to allow k8s to work but a little more lax than we'd like. We are considering an alternative here: buildpacks/lifecycle#343