Azure kubernetes - Secure pod access to resources - azure

Question

I am coming from Windows OS background and have limited knowledge on Linux.
As per the Microsoft documentation
For your applications to run correctly, pods should run as a defined user or group and not as root. The securityContext for a pod or container lets you define settings such as runAsUser or fsGroup to assume the appropriate permissions. Only assign the required user or group permissions, and don't use the security context as a means to assume additional permissions. The runAsUser, privilege escalation, and other Linux capabilities settings are only available on Linux nodes and pods.
and they provided the below sample
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
fsGroup: 2000
containers:
- name: security-context-demo
image: nginx:1.15.5
securityContext:
runAsUser: 1000
allowPrivilegeEscalation: false
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
Based on the given description, I understood that pod is not given root access and given limited access on network & time.
What does runAsUser: 1000 & fsGroup: 2000 mean? How to setup the fsGroup?

Answer 1

runAsUser: 1000 field specifies that for any Containers in the Pod, all processes run with user ID 1000
fsGroup: 2000 specifies all processes of the container are also part of the supplementary group ID 2000.This group ID is associated with the emptyDir volume mounted in the pod and with any files created in that volume. You should remember that only certain volume types allow the kubelet to change the ownership of a volume to be owned by the pod. If the volume type allows this (as emptyDir volume type) the owning group ID will be the fsGroup.
One thing to remember with fsGroup is that when you try to mount a folder from your host. As Docker mounts the host volume preserving UUID and GUID from the host, permission issues in the Docker volume are possible. The user running the container may not have the appropriate privileges to write in the volume.
Possible solutions are running the container with the same UUID and GUID as the host or change the permissions of the host folder before mounting it to the container.
For more details on fsGroup refer to docs