Service Accounts in Kubernetes: A Secure Way to Manage Pod Permissions

In this article, we delve into the concept of Service Accounts in Kubernetes, their importance, and how they contribute to securing access to cluster resources. Below, we’ll explore how Service Accounts can limit API access and reduce vulnerabilities in your Kubernetes environment.

⚠️ This is a Two-Part Article: FREE vs PAID

🔓 Free Access for All Readers:
In this free section, you’ll gain an understanding of the fundamentals of Kubernetes Service Accounts, including:

• What Service Accounts are and how they differ from user accounts.
• How Service Accounts help secure API access and control pod interactions.
• The basic principles of minimizing privileges to enhance security.

🔐 Exclusive for Paid Members:

Access In-Depth Code Examples & Detailed Explanations

As a premium member, you’ll unlock access to code snippets and in-depth walkthroughs, including:

• How to create and configure custom Service Accounts
• Step-by-step RBAC roles setup with minimal privileges
• Binding roles to service accounts to enhance security

Join our premium devops or security membership to access the full code and in-depth explanations.

Summary

🔓 Free Access for All Readers:

I. Introduction to Service Accounts in Kubernetes

• Definition of a Service Account
• Differences between user accounts and service accounts
• Importance of Service Accounts for pod and container interactions with the Kubernetes API

II. The Purpose of Service Accounts

• Providing API access for pods
• Enabling authorization through Roles and RoleBindings
• Establishing security boundaries through minimal privileges

III. Key Security Considerations for Service Accounts

1. Principle of Least Privilege
   • Minimizing permissions to reduce risks
2. Isolation of Vulnerable Components
   • Limiting damage from compromised applications
3. Prevention of Lateral Movement
   • Restricting access across different namespaces
4. Minimizing API Access
   • Avoiding unnecessary API exposure
5. Avoiding Default Service Accounts
   • Customizing service accounts for specific workloads

IV. Benefits of Securing Service Accounts

• Limiting API access to protect against attacks
• Preventing unauthorized access to other namespaces
• Containing security breaches
• Preventing resource deletion or modification
• Custom control over permissions

🔐 Exclusive for Paid Members ONLY:

V. How to Secure a Service Account (Code Examples)

• Creating a custom service account
• Defining a Role with minimal privileges
• Binding the Role to the service account
• Assigning the service account to a pod

VI. Conclusion

• The importance of securing service accounts in vulnerable namespaces
• Following the principle of least privilege to reduce risks in Kubernetes environments

What is a Service Account?

A Service Account in Kubernetes is a special type of account used by pods and containers to interact with the Kubernetes API. It provides an identity for processes that run within a pod and is essential for controlling access to cluster resources. Unlike a user account (which is used by humans), service accounts are used by applications and workloads running within the cluster.

Every pod running in Kubernetes automatically gets a service account assigned to it, which it uses to authenticate with the Kubernetes API for tasks such as:

• Retrieving secrets
• Reading or creating ConfigMaps
• Communicating with other Kubernetes resources (like PersistentVolumeClaims, services, etc.)

Each namespace comes with a default service account, but you can create custom service accounts with tailored permissions to enhance security.

Purpose of a Service Account

The primary purposes of a service account are:

1. API Access: It provides an identity that pods use to authenticate with the Kubernetes API to interact with resources within the cluster.
2. Authorization: A service account can be linked to Roles and RoleBindings that define what actions the pod can perform. These roles dictate what the service account (and therefore, the pod) can do (e.g., read secrets, modify resources, etc.).
3. Security Boundaries: By creating and configuring service accounts with minimal privileges, you can restrict a pod’s access to only what is necessary for the application to function.

Why Setting a Secure Service Account Increases Security

Securing a service account is a critical aspect of enhancing the security of any namespace, especially a vulnerable one. Here’s why:

1. Principle of Least Privilege

The Principle of Least Privilege (PoLP) dictates that entities (users, service accounts, etc.) should have the minimum privileges necessary to perform their tasks. By default, Kubernetes assigns a service account with no explicit roles, which gives it limited access to the Kubernetes API. However, many workloads might require specific access to secrets, resources, or APIs, and without a custom, restricted service account, you might risk over-granting permissions.

• A secure service account ensures that the pod can only interact with the resources necessary for its operation, reducing the risk that a compromised application could escalate privileges or interact with unauthorized resources.

2. Isolation of Vulnerable Components

If a service account associated with a vulnerable application is compromised, the attacker might exploit the Kubernetes API using the service account’s permissions. By restricting what the service account can do, you limit the damage an attacker can cause if they compromise the application.

• For example, if you only grant the service account read-only access to certain resources (like ConfigMaps), even if an attacker gains control, they can't escalate privileges to delete resources, modify configurations, or access secrets beyond the defined scope.

3. Prevention of Lateral Movement

Lateral movement refers to the ability of attackers to move across systems after gaining a foothold. If a vulnerable application in the hello world namespace uses a service account with unrestricted access, the attacker can use it to interact with other parts of the cluster.

• By using a tightly scoped service account, you prevent the vulnerable application from accessing resources outside of its namespace, which helps contain any security breach and limits lateral movement to other parts of the cluster.

4. Minimizing API Access

Pods should not have access to the Kubernetes API unless it's necessary for the application to function. By removing unnecessary access to the Kubernetes API (e.g., granting read-only or namespace-limited access), you reduce the attack surface.

• For a vulnerable application, granting excessive API access could expose sensitive information or lead to cluster-wide attacks. A restricted service account minimizes this risk.

5. Avoiding Use of the Default Service Account

Kubernetes automatically assigns a default service account to each pod if no other service account is specified. This default service account has limited permissions, but it’s a common best practice to avoid using the default account, especially for sensitive or vulnerable workloads.

• Creating a custom service account gives you more control over what that account can do, ensuring that you follow security best practices by assigning only the necessary permissions.

Benefits of a Secure Service Account in the Namespace

1. Limits API Access: By using a service account with minimal permissions, the vulnerable application cannot make unnecessary API requests. This reduces the risk of API misuse if the application is compromised.
2. Prevents Unauthorized Access: A secure service account restricts the pod’s access to other namespaces and resources, ensuring that even if the vulnerable application is exploited, it can’t access other sensitive parts of the cluster.
3. Containment of Security Breaches: If the service account is compromised, a tightly scoped service account will limit what the attacker can do. This isolates the breach to the hello world namespace and prevents damage to other workloads.
4. Prevents Resource Deletion or Modification: The service account can be set up to allow read-only access to necessary resources, preventing unauthorized modification or deletion of critical resources (e.g., ConfigMaps, Secrets).
5. Custom Control: Creating a custom service account gives you fine-grained control over what the pod can access. You can further customize roles and permissions as needed to ensure that the pod only has access to resources required for its operation.

How to Secure a Service Account in the hello-world Namespace

I - Create a Custom Service Account: Instead of using the default service account, create a custom service account specifically for the pods running in the hello-world  namespace

apiVersion: v1
kind: ServiceAccount
metadata:
  name: hello-world-secure-sa
  namespace: hello-world

II - Create Minimal Role with Least Privileges: Define a Role that grants only the necessary permissions to the service account. For example, if the vulnerable application only needs access to ConfigMaps, create a read-only role for ConfigMaps: