Home > Software engineering >  kubernetes use singular service account token secret
kubernetes use singular service account token secret

Time:08-19

I want all of my pods to have the same kubernetes service account token so that my caching proxy views all requests from a single deployment as equivalent.

I've always taken it for granted that I'll get these service account tokens automatically made in the kubernetes namespace with a random string at the end like:

service-account-token-qrs88x

I thought this would automount this token into all of my pods, but it seems like every pod gets their own token.

I can create a token for which I have a dependable name, but I was wondering if I could save myself some extra configuration by using these automatically generated token Secrets as part of a deployment instead of each pod getting their own token.

What is the point of service-account-token-qrs88x if I can't reliably use it inside a pod?

CodePudding user response:

I thought this would automount this token into all of my pods, but it seems like every pod gets their own token.

No, every namespace got only default, its might be your deployment that creates a random service account.

The default service account is bound to every in the namespace, so you can assign permission to the default pod and as this is already used by the pod inside the namespace.

kubectl create rolebinding default-view \
  --clusterrole=view \
  --serviceaccount=default:default \
  --namespace=default

this is just example, you can assign base on your need.

Every Kubernetes installation has a service account called default that is associated with every running pod. Similarly, to enable pods to make calls to the internal API Server endpoint, there is a ClusterIP service called Kubernetes. This combination makes it possible for internal processes to call the API endpoint.

The default secret mount to /tmp/secrets/kubernetes.io/serviceaccount/token

So if you want to use service token for example, that service account allow service to use AWS s3, or some GCP service, then you should create another service and allow pod to use that service.

this will create service account named myserviceaccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myserviceaccount
  annotations:
   eks.amazonaws.com/role-arn: {{ .Values.ses_role_arn }}
  namespace: {{ .Release.Namespace }}
  labels:
    app.kubernetes.io/name: {{ include "helm-chart.name" . }}
    helm.sh/chart: {{ include "helm-chart.chart" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}

and the pod should reference this service account

    spec:
      imagePullSecrets:
        - name: {{ include "helm-chart.fullname" . }}
      volumes:
        - name: heap-dumps
          emptyDir: {}
      serviceAccountName: myserviceaccount    
      containers:.....

enter image description here enter image description here

Or you can consume the token as env from the default service token, so you will not relay on the token name.


apiVersion: v1
kind: Secret
metadata:
  name: default-token
  annotations:
    kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
---
apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: mycontainer
    image: nginx
    env:
      - name: KUBERNETES_TOKEN
        valueFrom:
          secretKeyRef:
            name: default-token
            key: token
  restartPolicy: Never

  • Related