Windows build images use SIDs for User/Group ownership

[micahyoung]

Readable

[jabrown85]

This might be out of scope for this, but how does kubernetes translate things like this in for windows based pods?

securityContext:
    fsGroup: <group-id>

I'm trying to imagine writing a single platform that can target windows and linux builders with a single implementation. Right now, a platform may read the CNB_GROUP_ID from the target builder and pop that into the securityContext for the pod so that volume ownership is as expected.

[ekcasey]

On linux there are certain cases where the lifecycle need to be launched as root to access certain resources. For example, when pack runs certain phases in a daemon build it runs the container as root. The lifecycle opens a connection to the daemon socket before dropping privileges for the rest of the build. When run as root the lifecycle will also chown certain directories (cache, layers) if they are not writable as the unprivileged user (although this could be made unnescessary if the builder was required to provide the mount points with the correct permissions).

Have you investigated whether any of these concerns are relevant for windows containers and, if so, are the inputs above sufficient to perform analogous actions on windows?

[micahyoung]

Definitely very relevant and while the current lifecycle implementation is unimplemented, it should be feasible to do so using Windows APIs like AdjustTokenPrivileges or LogonUserW (which have wrappers in x/sys/windows)

[micahyoung]

After digging in a bit more, it seems this impersonation behavior should work for Windows. There's not a lot of well documented examples out there but I stumbled on this Powershell Proof-of-concept demonstrating how an Administrator user can impersonate the SYSTEM user - technically to gain, rather than lose privileges - but translating this to Golang and to use the user SID instead of SYSTEM should be feasible, though maybe not trivial. I confirmed this PoC works when run as ContainerAdministrator on a servercore container (b/c only servercore has Powershell) so there's no container magic that should get in the way and I assume it's likely to work on nanoserver for binaries using the same Windows syscalls.

As for the specifics of establishing daemon socket connections and chowning files before dropping privileges, I'd have to continue to investigate, but it feels close enough that I assume we could find a workaround, if not use the same implementation.

But all the inputs as far as user/group SIDs are sufficient to do impersonation.

[ekcasey]

It it worth having create-builder automatically set CNB_USER_SID and CNB_GROUP_SID if it find that the build image is using one of the well known users? This might reduce burden on end users.

[micahyoung]

Great suggestion, particularly since Docker's hard-coded ContainerUser/ContainerAdministrator SIDs that will most commonly be used, aren't well-known Windows SIDs. Having most stacks follow this pattern could also give us a mitigation if the SIDs ever changed for some reason.

I'll update the RFC with this suggestion

[micahyoung]

I was going to add some text for that option but was wondering if it starts to contradict valid build image requirements of the spec:

Under Build Image

The platform MUST ensure that:

The image config's Env field has the environment variable CNB_USER_ID set to the user †UID/‡SID of the user specified in the User field.

(We'll be tweaking the var name here of course)

But I'm now feeling like, while this helps with pack builders, this may cause some delayed confusion in a case where a Stack Author makes a "build image" w/o the env vars, that works with pack but, potentially much later, a platform like kpack fails to validate while trying to make a cluster builder or something.

Perhaps, instead we could add a more helpful error message during pack builder create - when the env vars are missing, suggest the value to go back and add to the build image, based on a lookup table for ContainerUser, ContainerAdministrator (and perhaps even a /etc/passwd check for Linux images, if we wanted to go that far).

[hone]

Do we need to close the loop on this?

[micahyoung]

This might be out of scope for this, but how does kubernetes translate things like this in for windows based pods?

securityContext:
    fsGroup: <group-id>

I'm trying to imagine writing a single platform that can target windows and linux builders with a single implementation. Right now, a platform may read the CNB_GROUP_ID from the target builder and pop that into the securityContext for the pod so that volume ownership is as expected.

@jabrown85 I think the Windows equivalent securityContext (docs) would be:

  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"

... so you'd likely end up grabbing the CNB_USER_SID instead to do the same for a Windows pod.

Does that line up with the use-case? Would the Group vs User mismatch be problematic?

[jabrown85]

Does that line up with the use-case? Would the Group vs User mismatch be problematic?

That will probably be 👍

[yaelharel]

There are many "or" in this sentence. Maybe it's better to have a list instead.

[ekcasey]

Final Comment Period with merge disposition, closing on 17 February, 2021