Katkat

Give a Kubernetes Pod a Token to Call an External Service Securely

AppleSoftware Engineer · Technical Screen

Last updated

Decide how a Kubernetes pod should obtain a token for calling an external service. Tests knowledge of Secrets delivered as volumes or environment variables, RBAC and encryption at rest, external secret managers, workload identity with projected service account tokens, and rotating the token without downtime.

An application running in a Kubernetes pod has to call an external service, outside the cluster, that authenticates every request with a token. How do you get that token to the pod?

Lay out the options, compare them on security, rotation and operational cost, and recommend one, explaining when you would choose differently.

Clarifying Questions

  • Is the token a long-lived static key issued by the external service, or can the service accept short-lived credentials from an identity provider, through OIDC federation or a cloud IAM role?
  • Does the cluster run on a cloud provider with workload identity, and is a secrets manager already in use?
  • How often must the token be rotated, and can the application pick up a new token without a restart?
  • Who else can create pods or read Secrets in the namespace?

Hints

Hint 1

Follow the token: Trace the token from where it is issued to the process that sends it, and at each step ask where it is stored and who else can read it.

Hint 2

Does the pod need a long-lived secret at all?: Consider whether the pod's own identity in the cluster could be exchanged for a short-lived credential.

Follow-up questions

  • If the token comes from a Secret mounted into the pod as a volume, who else can read it, and how does a rotated value reach the running process?
  • The external service supports OIDC federation. How can the pod authenticate without any stored secret?
  • How do you keep the token out of the Git repository that holds your manifests?
  • The token has leaked. What can an attacker do with it, and how do you respond?