Default vs. Custom ServiceAccounts: Securing API Access for Kubernetes Pods

In Kubernetes, ServiceAccounts are integral to how processes within a Pod securely communicate with the API server. By default, every Pod is assigned a ServiceAccount, enabling access to the Kubernetes API. However, for more fine-grained security and better control over permissions, creating and using custom ServiceAccounts is often preferable. This article explores the differences between default and custom ServiceAccounts and explains how they contribute to a more secure and manageable Kubernetes environment.

What Are ServiceAccounts in Kubernetes?

A ServiceAccount in Kubernetes acts like a user account, but for Pods and other in-cluster resources. Just as a user logs in with credentials to interact with the Kubernetes API, a Pod or an internal process within Kubernetes also requires credentials to access API resources. Kubernetes handles these credentials through ServiceAccounts, which are specifically designed to secure this internal access.

The Default ServiceAccount

When you create a Pod in Kubernetes without specifying a ServiceAccount, it automatically receives a default ServiceAccount that is scoped to the namespace where the Pod is deployed. This default ServiceAccount is created along with the namespace and gives the Pod basic access to the API.

• Namespace-Specific: The default ServiceAccount is unique to each namespace, meaning every namespace has its own isolated default account.

• Automatic Mounting: Kubernetes mounts the token for this default ServiceAccount within the Pod, typically at /var/run/secrets/kubernetes.io/serviceaccount. This setup means that any application running within the Pod can access the token by default.

The default ServiceAccount is convenient for simple use cases, but it comes with potential security risks. By relying on a generic account, there may be a lack of control over which Pods have access to specific API endpoints, increasing the attack surface if not managed carefully.

Creating a Custom ServiceAccount

For applications that require distinct access permissions, creating a custom ServiceAccount is a best practice. Custom ServiceAccounts allow you to define specific access permissions and prevent all Pods in a namespace from sharing the same API access level. Here’s how you can create and assign a custom ServiceAccount in Kubernetes:

1. Create a Custom ServiceAccount:

    kubectl create serviceaccount custom-sa
   

   This command creates a new ServiceAccount named custom-sa in the default namespace (or any specified namespace).

2. Configure Pod to Use the Custom ServiceAccount: In your Pod specification, add the serviceAccountName field to associate the Pod with this custom ServiceAccount:

    apiVersion: v1
    kind: Pod
    metadata:
      name: custom-pod
    spec:
      serviceAccountName: custom-sa
      containers:
      - name: my-container
        image: my-app-image
   

   By specifying custom-sa in the Pod spec, Kubernetes will mount the credentials for custom-sa instead of the default ServiceAccount. This approach gives you better control over the Pod’s permissions and API access.

Setting Custom Permissions with Role-Based Access Control (RBAC)

Kubernetes offers Role-Based Access Control (RBAC) to define what a ServiceAccount can or cannot do within a namespace or across the entire cluster. With RBAC, you can assign specific roles to a custom ServiceAccount, controlling access to Kubernetes resources as needed:

1. Define a Role: Create a Role that lists the allowed actions within a namespace. Here’s an example role that only allows reading pods:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      namespace: default
      name: pod-reader
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "list"]
   

2. Bind the Role to the ServiceAccount: Use a RoleBinding to associate the role with your custom ServiceAccount:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: read-pods-binding
      namespace: default
    subjects:
    - kind: ServiceAccount
      name: custom-sa
      namespace: default
    roleRef:
      kind: Role
      name: pod-reader
      apiGroup: rbac.authorization.k8s.io
   

With these configurations, the custom ServiceAccount custom-sa can only list and retrieve Pod information within the default namespace, providing a secure and limited access profile tailored to its purpose.

Benefits of Using Custom ServiceAccounts

Using custom ServiceAccounts offers several advantages:

• Enhanced Security: By specifying unique access rules for each ServiceAccount, you minimize the risk of accidental or malicious access to critical resources.

• Namespace Isolation: Custom ServiceAccounts are namespace-scoped, allowing you to limit API access within specific namespaces, which is beneficial for multi-tenant environments.

• Fine-Grained Access Control: Custom ServiceAccounts, combined with RBAC, provide a way to define exact permissions, reducing unnecessary access.

Conclusion

Kubernetes ServiceAccounts are a powerful way to manage API access for applications running within a cluster. While the default ServiceAccount provides a convenient baseline, creating and using custom ServiceAccounts with defined roles offers improved security and control. This practice is essential in a production environment where multiple applications or teams may share the same cluster but require different access levels.

By leveraging custom ServiceAccounts and RBAC, you can ensure that each Pod has only the permissions it needs, enhancing the overall security and reliability of your Kubernetes cluster.