Service accounts in Kubernetes - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a Service Account in Kubernetes?

A Service Account in Kubernetes is a special type of account used by applications running in pods to interact with the Kubernetes API securely without using a user's credentials.

beginner

How does a Service Account differ from a regular user account in Kubernetes?

Service Accounts are meant for processes running inside pods, while user accounts are for humans. Service Accounts are managed by Kubernetes and provide tokens automatically to pods.

beginner

What is the default Service Account in a Kubernetes namespace?

Every Kubernetes namespace has a default Service Account named 'default'. Pods that do not specify a Service Account use this one automatically.

intermediate

How do you assign a specific Service Account to a pod?

You specify the Service Account name in the pod's YAML file under the 'serviceAccountName' field in the pod spec.

intermediate

Why is it important to use Service Accounts instead of user credentials inside pods?

Using Service Accounts limits access to only what the pod needs, improving security by avoiding sharing user credentials and enabling fine-grained permissions.

What does a Kubernetes Service Account provide to a pod?

A A user login for the pod

B An API token to access the Kubernetes API

C A network IP address

D A storage volume

Service Accounts provide pods with API tokens to securely access the Kubernetes API.

Which field in a pod spec sets the Service Account to use?

A podAccount

B accountName

C userAccount

D serviceAccountName

The 'serviceAccountName' field specifies which Service Account the pod uses.

What is the name of the default Service Account in every Kubernetes namespace?

A system

B admin

C default

D kube-service

The default Service Account is named 'default' in every namespace.

Why should you avoid using user credentials inside pods?

A They can give too much access and are less secure

B They are slower to authenticate

C Pods cannot use user credentials

D User credentials expire too quickly

User credentials can give pods more access than needed and pose security risks.

How does Kubernetes provide the Service Account token to a pod?

A Mounted as a secret volume inside the pod

B Sent via environment variables

C Printed in pod logs

D Manually copied by the user

Kubernetes mounts the Service Account token as a secret volume inside the pod automatically.

Explain what a Kubernetes Service Account is and why it is used.

Think about how pods talk to Kubernetes safely.

Describe how to assign a specific Service Account to a pod and why you might want to do this.

Consider controlling what a pod can do.

Practice

1. What is the main purpose of a ServiceAccount in Kubernetes?

easy

A. To schedule pods on specific nodes

B. To give a pod an identity and control its permissions inside the cluster

C. To manage network policies between pods

D. To store container images for pods

Solution

1. Step 1: Understand what identity means in Kubernetes

   A ServiceAccount provides an identity for pods so they can authenticate to the Kubernetes API.

2. Step 2: Recognize the role of permissions

   ServiceAccounts are linked to permissions (via Roles or ClusterRoles) to control what pods can do.

3. Final Answer:

   To give a pod an identity and control its permissions inside the cluster -> Option B

4. Quick Check:

   ServiceAccount = Pod identity and permissions [OK]

Hint: ServiceAccount = pod identity + permissions [OK]

Common Mistakes:

• Confusing ServiceAccount with image storage
• Thinking ServiceAccount manages pod scheduling
• Mixing ServiceAccount with network policies

2. Which of the following is the correct YAML snippet to create a ServiceAccount named my-service-account?

easy

A. apiVersion: apps/v1
kind: Deployment
metadata:
name: my-service-account

B. apiVersion: v1
kind: Pod
metadata:
name: my-service-account

C. apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account

D. apiVersion: v1
kind: Namespace
metadata:
name: my-service-account

Solution

1. Step 1: Identify the correct kind for ServiceAccount

   The kind must be ServiceAccount to create a service account resource.

2. Step 2: Check the apiVersion and metadata

   ServiceAccount uses apiVersion: v1 and metadata with the name field.

3. Final Answer:

   apiVersion: v1 kind: ServiceAccount metadata: name: my-service-account -> Option C

4. Quick Check:

   ServiceAccount YAML uses kind: ServiceAccount [OK]

Hint: ServiceAccount YAML always uses kind: ServiceAccount [OK]

Common Mistakes:

• Using wrong kind like Pod or Deployment
• Wrong apiVersion for ServiceAccount
• Confusing Namespace with ServiceAccount

3. Given this command: kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}', what does it output?

medium

A. The name of the first secret linked to the default ServiceAccount

B. The list of all pods using the default ServiceAccount

C. The token value inside the secret

D. An error because jsonpath is invalid

Solution

1. Step 1: Understand the command structure

   The command fetches the ServiceAccount named 'default' and extracts the first secret's name using jsonpath.

2. Step 2: Interpret the jsonpath expression

   The expression {.secrets[0].name} selects the name of the first secret linked to the ServiceAccount.

3. Final Answer:

   The name of the first secret linked to the default ServiceAccount -> Option A

4. Quick Check:

   jsonpath extracts secret name from ServiceAccount [OK]

Hint: jsonpath {.secrets[0].name} gets first secret name [OK]

Common Mistakes:

• Thinking it lists pods instead of secrets
• Expecting secret token value instead of secret name
• Assuming jsonpath syntax is wrong

4. You created a ServiceAccount but your pod fails to use it. Which of these is the most likely cause?

medium

A. The ServiceAccount was created in a different namespace

B. The pod image is missing

C. The ServiceAccount has no secrets linked

D. The pod spec does not specify the ServiceAccount name

Solution

1. Step 1: Check namespace consistency

   ServiceAccounts are namespace-scoped. If the pod is in one namespace but the ServiceAccount in another, the pod cannot use it.

2. Step 2: Verify pod spec and ServiceAccount existence

   Even if the ServiceAccount exists in the same namespace, the pod must specify the ServiceAccount name in its spec to use it.

3. Final Answer:

   The pod spec does not specify the ServiceAccount name -> Option D

4. Quick Check:

   Pod spec must specify serviceAccountName to use it [OK]

Hint: Pod spec must specify serviceAccountName [OK]

Common Mistakes:

• Forgetting to specify serviceAccountName in pod spec
• Assuming missing secrets cause pod failure
• Blaming pod image unrelated to ServiceAccount

5. You want a pod to use a custom ServiceAccount named app-sa and access the Kubernetes API with limited permissions. Which steps should you follow?

hard

A. Create the ServiceAccount app-sa, create a Role with permissions, bind the Role to app-sa, then specify serviceAccountName: app-sa in the pod spec

B. Create a RoleBinding for the default ServiceAccount, then deploy the pod without specifying serviceAccountName

C. Create a ClusterRole with full permissions and assign it to the pod directly

D. Deploy the pod first, then create the ServiceAccount and Role

Solution

1. Step 1: Create the custom ServiceAccount

   Define and create app-sa in the pod's namespace to give the pod an identity.

2. Step 2: Define permissions and bind them

   Create a Role with limited permissions and bind it to app-sa using a RoleBinding.

3. Step 3: Specify the ServiceAccount in the pod spec

   Set serviceAccountName: app-sa in the pod spec so the pod uses this identity and permissions.

4. Final Answer:

   Create the ServiceAccount app-sa, create a Role with permissions, bind the Role to app-sa, then specify serviceAccountName: app-sa in the pod spec -> Option A

5. Quick Check:

   Custom ServiceAccount + Role + RoleBinding + pod spec = correct setup [OK]

Hint: Create SA, Role, RoleBinding, then assign SA to pod [OK]

Common Mistakes:

• Assigning permissions to default ServiceAccount instead of custom
• Creating ClusterRole with too many permissions
• Deploying pod before creating ServiceAccount and Role