[SPARK-43171][K8S] Support custom Unix username in Pod

[pan3793]

What changes were proposed in this pull request?

This PR allows the users to custom Unix username in Pod by setting env var SPARK_USER_NAME, which reduces the gap between Spark on YARN and K8s.

Each line in /etc/passwd is compose of

username:password:UID:GID:comment:home_directory:shell

This PR simply changes the first item from $myuid to ${SPARK_USER_NAME:-$myuid} to achieve the above ability.

Why are the changes needed?

In Spark on YARN, when we launch a Spark application via spark-submit --proxy-user jack ..., the YARN will launch containers(usually Linux processes) using Unix user "jack", and some components/libraries rely on the login user in default, one example is Alluxio
https://github.com/Alluxio/alluxio/blob/da77d688bdbb0cf0c6477bed4d3187897fe2a2e1/core/common/src/main/java/alluxio/conf/PropertyKey.java#L6469-L6476

  public static final PropertyKey SECURITY_LOGIN_USERNAME =
      stringBuilder(Name.SECURITY_LOGIN_USERNAME)
          .setDescription("When alluxio.security.authentication.type is set to SIMPLE or "
              + "CUSTOM, user application uses this property to indicate the user requesting "
              + "Alluxio service. If it is not set explicitly, the OS login user will be used.")
          .setConsistencyCheckLevel(ConsistencyCheckLevel.ENFORCE)
          .setScope(Scope.CLIENT)
          .build();

To reduce the difference between Spark on YARN and Spark on K8s, we hope Spark on K8s keeps the same ability to allow to dynamically change login user on submitting Spark application.

Does this PR introduce any user-facing change?

Yes, it allows the user to custom Pod Unix username by setting env var SPARK_USER_NAME in K8s, reducing the gap between Spark on YARN and K8s.

How was this patch tested?

New IT is added.

Also manually testing in our internal K8s cluster.

spark-submit --master=k8s://xxxx \
        --conf spark.kubernetes.driverEnv.SPARK_USER_NAME=tom \
	--conf spark.executorEnv.SPARK_USER_NAME=tom \
	--proxy-user tom \
        ...

Then login the Pod, verify the Unix username by id -un is tom instead of 185

[pan3793]

SPARK_USER_NAME is introduced in SPARK-26015(#23017), and I guess supporting dynamic user name is one of the author initial intention

[pan3793]

cc @Yikun

[Yikun]

@pan3793 Thanks! We had some discussion discussed this in apache/spark-docker#11 .

A quick question: are you plan to also support it in apache/spark-docker (I guess dynamic switch user might a little bit difficult based on Docker Official Image rule), or to say it's a k8s only feature?

[pan3793]

@Yikun I suppose it's a K8s-only feature.

As mentioned in the PR description, the main purpose is to reduce the gap between Spark on YARN and K8s, to allow users seamlessly migrate Spark jobs from YARN to K8s.

I don't have much knowledge about docker/container technology, and I agree w/ you it looks not easy to dynamically switch user based on the Docker Official Image rule

[pan3793]

Also cc @yaooqinn

[Yikun]

@pan3793 Thanks. LGTM, also cc @dongjoon-hyun @holdenk

[Yikun]

Just for others reviewer infomation, I also wanna share some considerations about this (also include some idea in offline discussion with @pan3793 ):

1. (-0.5) As per docker official recommendation about USER, we should use groupadd and useradd to address, rather than change /etc/passwd directly. If we specify the USER (useradd/groupadd) in Dockerfile in future, this change will be ignored.
2. (-0.5) In theory, application users should be decoupled from container users. Such as, spark docker image should use static user spark (just like we done in spark-docker), and other application respect the spark user, or don’t depends on the container user.
3. (+0.5) As per [SPARK-26015][K8S] Set a default UID for Spark on K8S Images #23017 original design, it was intend to switch user name dynamically.
4. (+0.5) Consider the Spark case, there are many users want to migrate YARN to K8s easily, support user dynamic switch is a reasonable case.
5. (+0.5) It's a K8s only feature, not for Docker image, so 1 / 2 could be balanced in some level.

So, I am +0.5 on this PR. : )

[DerekTBrown]

@pan3793 are we good to merge?

[dongjoon-hyun]

Do you think you can add an integration test case in order to prevent a future regression, @pan3793 ?

[pan3793]

@Yikun A new tag is added, you can use it to exclude this test for apache/spark-docker GA

[pan3793]

Do you think you can add an integration test case in order to prevent a future regression, @pan3793 ?

Sure, IT is added.

[pan3793]

@Yikun @dongjoon-hyun would you please take a look again?

[Yikun]

Frankly, I'm unsure about this now, the mainly concern is that it depends on the /etc/passwd, according latest DOI review, it might bring some wider permisson issue (docker-library/official-images#13089 (comment) see question 4/5). Use the usermod -l in entrypoint might the solution I can think out.

I also try to find help from the DOI to seek better solution, so maybe wait the reply maybe for some day?

[holdenk]

So I would say this looks ok to me, but I hear the concerns around modifying /etc/passwd so I agree on waiting to to see what comes out of the DOI discussions.

[Yikun]

Here is the solution to resolve /etc/passwd permission issue according to DOI suggestion: apache/spark-docker#45. (use libnss to fake user)

I also had a offline discussion with @pan3793, it's also work for this case (if specified the SPARK_USER, then use the libnss to switch fake user).

[github-actions]

We're closing this PR because it hasn't been updated in a while. This isn't a judgement on the merit of the PR in any way. It's just a way of keeping the PR queue manageable.
If you'd like to revive this PR, please reopen it and ask a committer to remove the Stale tag!