What is the difference between a service account and a context in Kubernetes? - kubernetes

Question

What are the practical differences between the two? When should I choose one over the other?
For example if I'd like to give a developer in my project access to just view the logs of a pod. It seems both a service account or a context could be assigned these permissions via a RoleBinding.

Answer 1

What is Service Account?
From Docs
User accounts are for humans. Service accounts are for processes,
which run in pods.
User accounts are intended to be global...Service
accounts are namespaced.
Context
context related to kubeconfig file(~/.kube/config). As you know kubeconfig file is a yaml file, the section context holds your user/token and cluster references. context is really usefull when you have multiple cluster, you can define all your clusters and users in single kubeconfig file, then you can switch between them with help of context (Example: kubectl config --kubeconfig=config-demo use-context dev-frontend)
From Docs
apiVersion: v1
clusters:
- cluster:
certificate-authority: fake-ca-file
server: https://1.2.3.4
name: development
- cluster:
insecure-skip-tls-verify: true
server: https://5.6.7.8
name: scratch
contexts:
- context:
cluster: development
namespace: frontend
user: developer
name: dev-frontend
- context:
cluster: development
namespace: storage
user: developer
name: dev-storage
- context:
cluster: scratch
namespace: default
user: experimenter
name: exp-scratch
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
user:
client-certificate: fake-cert-file
client-key: fake-key-file
- name: experimenter
user:
password: some-password
username: exp
You can above, there are 3 contexts, holds references of cluster and user.
..if I'd like to give a developer in my project access to just view the
logs of a pod. It seems both a service account or a context could be
assigned these permissions via a RoleBinding.
That correct, you need to create service account, Role(or ClusterRole), RoleBinding(or ClusterRoleBinding) and generate kubeconfig file that contains service account token and give it your developer.
I have a script to generate kubconfig file, takes service account name argument. Feel free to check out
UPDATE:
If you want to create Role and RoleBinding, this might help

Answer 2

Service Account: A service account represents an identity for processes that run in a pod. When a process is authenticated through a service account, it can contact the API server and access cluster resources. If a pod doesn’t have an assigned service account, it gets the default service account.
When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace and you can access the API from inside a pod using automatically mounted service account credentials.
Context: A context is just a set of access parameters that contains a Kubernetes cluster, a user, and a namespace.
The current context is the cluster that is currently the default for kubectl and all kubectl commands run against that cluster.

Answer 3

They are two different concepts. A context most probably refers to an abstraction relating to the kubectl configuration, where a context can be associated with a service account.
For some reason I assumed a context was just another method of authentication.