Overview

Kubernetes service accounts offer a mechanism for processes running in a pod to interact with the Kubernetes API. By default, a pod utilizes the system's default service account; however, there are situations where specifying a non-default service account is necessary. This article guides you through configuring a non-default service account on a deployment, explaining when and why it might be needed and illustrating the process with examples.

Key Concepts

Service Account

A service account in Kubernetes is an identity assigned to pods that enables them to authenticate with the Kubernetes API and perform actions based on its associated permissions.

Non-Default Service Account

While each namespace has a default service account, creating and using a non-default service account grants specific permissions tailored to the application's requirements. This approach aligns with the principle of least privilege, ensuring pods have only the necessary permissions.

Why Use a Non-Default Service Account?

• Security: Restrict a pod's permissions to only what is necessary, minimizing potential attack surfaces.
• Compliance: Enforce stringent access controls using Role-Based Access Control (RBAC) policies.
• Isolation: When different parts of an application stack require varying levels of permissions, separate service accounts enhance security and manageability.

Configuring a Non-Default Service Account

Prerequisites

Ensure you have a running Kubernetes cluster and appropriate access permissions to create resources such as service accounts, roles, and role bindings.

Steps

1. Create a Service Account
   Execute the following command to create a non-default service account named custom-sa:

   kubectl create serviceaccount custom-sa

1. Define Permissions
   Use RBAC to define what this service account can do. For instance, a role that allows reading pods:

1   apiVersion: rbac.authorization.k8s.io/v1
2   kind: Role
3   metadata:
4     namespace: default
5     name: pod-reader
6   rules:
7   - apiGroups: [""]
8     resources: ["pods"]
9     verbs: ["get", "watch", "list"]

Apply the role using:

   kubectl apply -f role.yaml

1. Bind the Role to the Service Account
   Create a RoleBinding to associate the role with the custom-sa service account:

1   apiVersion: rbac.authorization.k8s.io/v1
2   kind: RoleBinding
3   metadata:
4     name: read-pods
5     namespace: default
6   subjects:
7   - kind: ServiceAccount
8     name: custom-sa
9     namespace: default
10   roleRef:
11     kind: Role
12     name: pod-reader
13     apiGroup: rbac.authorization.k8s.io

Apply the role binding using:

   kubectl apply -f rolebinding.yaml

1. Update the Deployment
   Modify the deployment manifest to specify the custom-sa service account:

1   apiVersion: apps/v1
2   kind: Deployment
3   metadata:
4     name: example-deployment
5   spec:
6     replicas: 2
7     selector:
8       matchLabels:
9         app: example
10     template:
11       metadata:
12         labels:
13           app: example
14       spec:
15         serviceAccountName: custom-sa
16         containers:
17         - name: example-container
18           image: nginx

Apply the changes with:

   kubectl apply -f deployment.yaml

Verification

To confirm that the pods are using the specified service account, run:

kubectl get pods --output=jsonpath='{..spec.serviceAccountName}' | sort | uniq

The output should display custom-sa, indicating successful configuration.

Summary Table

Additional Considerations

• Namespace Isolation: Ensure that the service account and related roles are created in the correct namespace, as permissions are namespace-specific unless using ClusterRoles.
• Secrets and ConfigMaps: If your application requires access to these resources, update the role accordingly.
• Audit and Logging: Implement checks to log API requests made by the service account for compliance and auditing purposes.

Conclusion

Configuring a non-default service account enhances your Kubernetes deployment's security posture by adhering to the principle of least privilege. This guide provides a foundational understanding and actionable steps to achieve a secure and compliant setup, tailored to specific organizational needs.