Lab 6.4.6, serviceAccountName vs securityContext runAsUser

docklander

Hi AKS gurus,

I have read kubernetes doco couple of times but i'm still not 100% clear the difference between pod running serviceAccountName vs securityContext runAsUser

especially lab 6.4.6, when securityContext runAsUser 1000 was removed the 2 pods are ran successfully.

the problem was '2018/04/13 19:51:13 emerg 11: mkdir() "/var/cache/nginx/client temp"failed (13: Permission denied)' user doesn't have privileges.

can someone explain me simple way. what is the clear difference between declare
'serviceAccountName' vs 'securityContext runAsUser'?

when both are declared 'serviceAccountName', 'securityContext runAsUser' which one gets used to run Pod or Container?

by testing. if both of them are there it's using the user 1000, from container ps aux

Q1. so is user 1000 trying to create temp was failing because of no privileges?
but this service account secret-access-sa, do not have privileges to create temp directory neither isn't it?

Q2. what is the difference between them 'serviceAccountName' vs 'securityContext runAsUser'

chrispokorni

Hi @docklander,

The service account resource allows Kubernetes applications defined by pods to be assigned permissions just like a user account. These permissions, defined with role based access control (RBAC) policies and bound to the service account, allow pods to interact with cluster resources. For example, a pod may be assigned elevated permissions to interact with the API server in order to create and/or delete other pods, something a pod may not be allowed to perform by default.

The runAsUser security context property targets the application process run by the container defined by the pod. The security context properties allow for process level permissions management, as the container's process interacts with container's environment and resources. For example, a process may or may not have permissions to create a file in a given path, or given an existing file a process may or may not have write permissions (but it may have only read permissions instead).

Hope this helps to differentiate the two concepts.

Regards,
-Chris