What happened
When exec-ing into the apl-operator container, standard identity commands fail:
```
groups: cannot find name for group ID 1001
groups: cannot find name for group ID 2000
whoami: failed to get username: No such id: 1001
```
The shell prompt also shows `I have no name!` instead of the expected username, indicating the container's user database has no entry for the UID the pod is running as.
What I expected
The container should run with a named user matching the UID/GID declared in the pod security context. `whoami` should return `app` and `groups` should resolve group names for IDs 1001 and 2000.
Steps to reproduce
- Deploy apl-operator with the Helm chart (default values, which set `runAsUser: 1001`, `runAsGroup: 1001`, `fsGroup: 2000`)
- Exec into the running container: `kubectl exec -n apl-operator deploy/apl-operator -c apl-operator -it -- bash`
- Run `whoami` — returns `failed to get username: No such id: 1001`
- Run `groups` — returns `cannot find name for group ID 1001` and `cannot find name for group ID 2000`
Additional context
The container image is built in two stages. The builder stage correctly creates the `app` user and `appfsgroup` group with explicit IDs matching the security context (UID 1001, GID 1001, secondary GID 2000). However, the final stage recreates the user using the `-r` (system/random) flag, which assigns a different, auto-generated UID/GID. The `appfsgroup` group (GID 2000) is not recreated in the final stage at all.
Because the final stage does not copy the user database from the builder, the running container's `/etc/passwd` and `/etc/group` only contain the randomly-assigned IDs — not 1001 or 2000 — while the pod security context forces those specific IDs at runtime. This creates the observed mismatch.
The fix should ensure the final stage uses the same explicit UID/GID values (1001 and 2000) as the security context, either by copying `/etc/passwd` and `/etc/group` from the builder stage or by recreating the user and group with explicit IDs in the final stage.
What happened
When exec-ing into the apl-operator container, standard identity commands fail:
```
groups: cannot find name for group ID 1001
groups: cannot find name for group ID 2000
whoami: failed to get username: No such id: 1001
```
The shell prompt also shows `I have no name!` instead of the expected username, indicating the container's user database has no entry for the UID the pod is running as.
What I expected
The container should run with a named user matching the UID/GID declared in the pod security context. `whoami` should return `app` and `groups` should resolve group names for IDs 1001 and 2000.
Steps to reproduce
Additional context
The container image is built in two stages. The builder stage correctly creates the `app` user and `appfsgroup` group with explicit IDs matching the security context (UID 1001, GID 1001, secondary GID 2000). However, the final stage recreates the user using the `-r` (system/random) flag, which assigns a different, auto-generated UID/GID. The `appfsgroup` group (GID 2000) is not recreated in the final stage at all.
Because the final stage does not copy the user database from the builder, the running container's `/etc/passwd` and `/etc/group` only contain the randomly-assigned IDs — not 1001 or 2000 — while the pod security context forces those specific IDs at runtime. This creates the observed mismatch.
The fix should ensure the final stage uses the same explicit UID/GID values (1001 and 2000) as the security context, either by copying `/etc/passwd` and `/etc/group` from the builder stage or by recreating the user and group with explicit IDs in the final stage.