Here’s my rough notes on a few docker insights courtesy of k8s that I would’ve probably missed otherwise:

Security contexts

DOCKER runs containers as a (somewhat diminished, comparatively speaking) “root”. If the docker file has a USER xxx directive, the default user it runs as is changed to the given user id. Further:

• docker run with cap-add [LINUX PRIVILEGE NAME] will allow you to add capabilities to the user
• docker run with cap-drop [LINUX PRIVILEGE NAME] to remove privs.
• docker run --privileged basically confers ALL privileges to the user (equiv to CAP_SYS_ADMIN)

In k8s, to achieve a similar thing (e.g. in pod yaml defn):

spec:
  securityContext:
    runAsUser: 1000
    # you cannot add linux privileges at pod level, must be at container level

or instead of on the pod (per above), can be applied directly to container:

spec:
  containers:
    - name: ubuntu
      image: ubuntu
      securityContext:
        runAsUser: 1000
        capabilities:
          add: 
          - NET_ADMIN

Container security context:

• overrides pod security context if there is one
• is where you must add/drop privileges/capabilities; can’t do that at pod level.

The ole ‘Entrypoint’ vs ‘Cmd’ thing.

So this little correspondence map is worth remembering too:

dockerfile	k8s .yaml	meaning
ENTRYPOINT ["foo"]	command: ["foo"]	the name of the executable or command to invoke
CMD ["3"]	args: [“3”]	the argument(s) as a list of string tokens

☝ Further, the args, or comand + args, can be overwritten when a container starts. We do it all the time in fact and don’t really stop to think about it.

Will add to these if more explicatory crosslinks pop up that are mildly useful / interesting.