luke6Lh43:
Hello, what would be the solution in lab “Service Account”, task 13 with the new approach (1.22 and above) ? The one in hints and the recording seems to be outdated:
IMHO, we should create Service Account, then create a token and mount it as a volume in the deployment template:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-dashboard
namespace: default
spec:
replicas: 1
selector:
matchLabels:
name: web-dashboard
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
name: web-dashboard
spec:
serviceAccountName: dashboard-sa
containers:
- image: <http://gcr.io/kodekloud/customimage/my-kubernetes-dashboard|gcr.io/kodekloud/customimage/my-kubernetes-dashboard>
imagePullPolicy: Always
name: web-dashboard
ports:
- containerPort: 8080
protocol: TCP
volumeMounts:
- mountPath: /var/run/secrets/tokens
name: dashboard-sa
volumes:
- name: dashboard-sa
projected:
sources:
- serviceAccountToken:
path: dashboard-sa
Mohamed Ayman:
Hello @luke6Lh43
Yes, You can configure this behavior for the spec of a Pod using a <Volumes | Kubernetes volume> type called ServiceAccountToken
luke6Lh43:
Thanks @Mohamed Ayman!
R:
Request some clarification, why should we perform the extra step of projected volume in spec ? Cant we achieve the same with just specifying serviceAccountName: in the POD spec ? As with this the POD is created with token created/mounted as projected volume ? I am just trying to clear my concepts
R:
@Mohamed Ayman @luke6Lh43 @unnivkn gentle follow-up on the above clarification. I am still not clear whey explicitly we need to inject the token as projected volume ? once we mention serviceAccountName in pod spec, the token is automount in the pod as projected volume (token generated by TokenRequestAPI using the service account admission controller as mentioned in the lecture). Please correct me if I am wrong, I am not sure whey we need to perform the extra step here ? Including @Alistair Mackay for help as well.
Alistair Mackay:
You are correct. The projected volume will be automatically added by the presence of serviceAccountName in your manifest
Alistair Mackay:
There’s also an option to disable the automount operation, but that’s only needed in CKS 
R:
yes, I also tested the scenario, of using the serviceAccountName which mounts the token as projected volume, created another test-sa service account and used that to inject the token in the pod. So the end result was, I am was able to get two tokens, from serviceAccountName automount feature in the default location, and projected token that I injected
