K8s

• Service Accounts

  • A ServiceAccount in Kubernetes is a key component for implementing secure access control.
  • It functions as a digital identity or non-human account, allowing Kubernetes system components, application pods, or other entities to authenticate and identify themselves securely within and outside the cluster
• Service Accounts

  • ServiceAccounts enable API authentication and facilitate identity and access control, thereby enhancing the security of Kubernetes environments.
  • While briefly introduced in the Intro to Kubernetes, a deeper understanding of ServiceAccounts is crucial for effective security management in Kubernetes.
• ServiceAccounts:

  • Are digital identities for non-human accounts.
  • Managed by Kubernetes itself.
  • Created using the Kubernetes API.
  • Have associated credentials stored as Secrets.
  • Enable non-human entities (like system components and application pods) to authenticate and interact with the cluster securely.
• Users:

  • Refer to human users who need access to the cluster.
  • Managed outside of Kubernetes.
  • Do not have a Kubernetes Object representing them.
  • Cannot be created or managed through the Kubernetes API.
  • User access is typically integrated with external account management systems such as LDAP or Active Directory.
• ServiceAccounts

  ServiceAccounts provide a streamlined method for associating accounts with specific tasks or processes within a Kubernetes cluster.

  • Lightweight: ServiceAccounts are designed to be lightweight, allowing for easy creation and management. They simplify defining granular permissions without the overhead of user account management systems, making it easier to adhere to security best practices.
  • Portable: Due to their lightweight and namespaced nature, ServiceAccounts can be easily bundled and used across different namespaces or projects, enhancing their portability and reusability.
• Service Accounts

  • Namespaced: ServiceAccounts are scoped to namespaces, meaning their names need only be unique within the namespace they belong to.
  • Each namespace has a default ServiceAccount named "default," which is assigned to pods if no other ServiceAccount is specified.
  • The default ServiceAccount has minimal permissions, so custom ServiceAccounts must be created for tasks requiring higher permissions.
• Use Cases for ServiceAccounts:

  1. API Communication: ServiceAccounts can grant pods the necessary permissions to interact with the Kubernetes API, such as retrieving secret or sensitive information with read-only access.
  2. Cross-Namespace Operations: When a pod in one namespace needs to manage resources in another namespace, a ServiceAccount with the appropriate Role-Based Access Control (RBAC) permissions can be used to facilitate this interaction.
• Use Cases for ServiceAccounts:

  1. External Service Authentication: ServiceAccounts can authenticate external services, such as CI/CD pipelines, with the Kubernetes cluster, ensuring secure and controlled access.
• Creating and Configuration of ServiceAccounts

  • Command: kubectl create serviceaccount example-name --namespace example-namespace
  • If you wanted this ServiceAccount to be associated with a specific pod, you would define that in the pod/deployment configuration YAML like so:

  
• RBAC

  • In Kubernetes, Role-Based Access Control (RBAC) is crucial for maintaining robust security, especially in preparing for worst-case scenarios where an attacker gains access to the cluster.
  • The objective is to ensure that even if an attacker gains authenticated access to a pod/application or user account, the permissions associated with these entities are limited to the least privilege necessary to perform their intended functions.
• RBAC

  • For instance, a pod tasked with checking the running status in the "x" namespace should only have permissions specific to that task.
  • If an attacker accesses this pod, their actions are restricted to the permissions granted, minimizing potential damage. RBAC enables this by precisely controlling permissions.
• Kubernetes Objects in RBAC:

  • Role: Defines what actions (verbs) can be performed on what resources. Permissions are additive, meaning there are no deny permissions. For example, a Role might allow "get" and "delete" actions on "pods" or "secrets." Roles are namespaced, meaning they apply within a specific namespace.
  • RoleBinding: Binds a Role to a ServiceAccount or User within a namespace. The Role specified in the RoleBinding must exist in the same namespace.
• Kubernetes Objects in RBAC:

  • ClusterRole: Similar to a Role, but it applies to cluster-wide resources, such as nodes, or across multiple namespaces. ClusterRoles are used when cluster-level access is necessary, adhering to the principle of least privilege.
  • ClusterRoleBinding: Binds a ClusterRole to a ServiceAccount or User, extending the permissions defined in the ClusterRole across the entire cluster.
• RBAC

  Example Use Case:

  • A pod that needs to monitor the status of other pods in the "x" namespace would have a Role allowing "get" actions on pods in that namespace.
  • A RoleBinding would then associate this Role with the ServiceAccount used by the monitoring pod.

  RBAC is essential for enforcing the principle of least privilege, ensuring that entities in the Kubernetes cluster have only the permissions they need to perform their functions and no more, thereby reducing the risk of damage in the event of a security breach.
• RBAC

  ServiceAccounts vs. Users:

  • ServiceAccounts: Used for granting authorization to applications or services, whether they are running within the cluster (like a pod) or are external third-party services (like Istio).
  • Users: Used for granting authorization to human users.
• Role/RoleBinding:

  • ServiceAccount: When an application or pod needs permission to perform certain actions on a namespaced resource, a Role and RoleBinding are used. For example, if a pod needs to get the running pods in a namespace, a Role allowing "get" actions on pods in that namespace is created, and a RoleBinding associates this Role with the ServiceAccount used by the pod.
• Role/RoleBinding:

  • User: For example, if user "Bob" is responsible for monitoring pods in the "dev" namespace, he should only have permissions to get pods in that specific namespace. A Role with the necessary permissions is created, and a RoleBinding associates this Role with Bob's user account.
• ClusterRole/ClusterRoleBinding:

  • ServiceAccount: If an application or pod needs to perform actions on cluster-level resources (like nodes), a ClusterRole and ClusterRoleBinding are used. For instance, if a pod needs to list all nodes in the cluster, a ClusterRole with the necessary permissions is created, and a ClusterRoleBinding associates this ClusterRole with the ServiceAccount used by the pod.
• ClusterRole/ClusterRoleBinding:

  • User: If user "Alice" is a cluster admin and needs to create multiple resource types across all namespaces, she requires cluster-level permissions. A ClusterRole with the necessary permissions is created, and a ClusterRoleBinding associates this ClusterRole with Alice's user account.
• RBAC

  ServiceAccount Example:

  • An application running in a pod needs to retrieve secrets within the "app" namespace. A Role is created with permissions to "get" secrets in the "app" namespace. A RoleBinding then binds this Role to the ServiceAccount used by the pod.
• RBAC

  User Example:

  • Bob is tasked with monitoring pods in the "dev" namespace. A Role is created with permissions to "get" pods in the "dev" namespace. A RoleBinding then binds this Role to Bob's user account.
  • Alice, a cluster admin, needs to set up resources across the cluster. A ClusterRole is created with permissions to "create" resources across all namespaces. A ClusterRoleBinding then binds this ClusterRole to Alice's user account.
• Defining RBAC

  • Let's say we have a pod that is supposed to check the running status of pods in the "example-namespace" namespace. The pod identifies as ExampleServiceAccount. The pod definition YAML may look something like this: 

  
• Defining RBAC

  • We then want to ensure that this pod has only the permissions required to perform this upcheck. To do this, we would first define a Role, looking something like this:  

  
• Defining RBAC

  • This role allows get, list, and watch verbs to be used ONLY on pods and ONLY in the example-namespace namespace. Next, we would need to bind this role to a user or ServiceAccount. Since our pod used the ServiceAccount ExampleServiceAccount, we want to bind this ServiceAccount to the up-checker-role. To do this, we would define a RoleBinding like so: 

  
• Accessing the Kubernetes API

  • Kubectl: This is Kubernetes' command-line tool. To access a cluster, you need the cluster's location and credentials. Once configured, kubectl locates and authenticates to the API server, enabling you to perform actions on the cluster using different kubectl commands. This is the most common method of accessing a Kubernetes cluster.
• Accessing the Kubernetes API

  • Proxy: Kubectl can run in "proxy mode" using the kubectl proxy command. This starts a proxy server on port 8080, forwarding requests to the Kubernetes API server. This method is recommended for direct access to the Kubernetes API as it uses the stored API server location and verifies the API server's identity using a self-signed certificate, preventing man-in-the-middle (MITM) attacks.
• Access the Kubernetes API

  • Auth Token: This method involves directly accessing the Kubernetes API by providing the HTTP client with the cluster location and credentials. However, it is not recommended due to vulnerability to MITM attacks.
  • Programmatic Access: Kubernetes supports programmatic access to the API using client libraries. Officially supported libraries include Python, Java, Javascript, and Go, along with some community-supported libraries, although these do not have official Kubernetes support.
• Kubernetes API Requests

  • When communicating with the Kubernetes API, you are requesting to perform actions such as getting logs, creating a pod, or deleting a service. Each request goes through multiple stages before being actioned.
• Kubernetes API Requests

  Authentication - Are you who you say you are?

  • Authenticating an API request can be done in multiple ways. 
  • Such as setting up client certificate authentication or using API bearer tokens. Authentication can also be done using other auth plugins such as Authenticating Proxy or HTTP basic auth.
  • Another authentication method would be ServiceAccount tokens, which are used to authenticate a Kubernetes ServiceAccount.
• Kubernetes API Requests

  Authentication - Are you who you say you are?

  • Multiple authentication methods can be used, and it is often the case that at least two would be used (ServiceAccount Tokens and another auth plugin for user authentication). A request passes this stage only when it has the right attributes needed to confirm the requestee identity.  
• Kubernetes API Requests

  Authorization:

  • After a requester's identity is authenticated, the next stage is determining if they have permission to perform the requested action. For example, if user example-user wants to delete example-pod, it must be verified whether they have sufficient permissions to do so
• Kubernetes API Requests

  Authorization:

  • RBAC (Role-Based Access Control): This is the most commonly used method and is crucial for security best practices. RBAC grants permissions based on roles assigned to users or ServiceAccounts.
  • Node Authorization: This method authorizes requests made by kubelet processes running on each node in the cluster. It is not intended for user authorization.
• Kubernetes API Requests

  Authorization:

  • ABAC (Attribute-Based Access Control): ABAC authorizes access based on attributes, such as user attributes (e.g., name, position), resource attributes (e.g., creation date, owner), or environmental attributes (e.g., time, location). While ABAC offers granular control, its complexity and maintenance can be challenging, making RBAC a preferred choice for many organizations due to its simpler implementation.
• Kubernetes API Requests

  Authorization:

  • Webhook: This method involves delegating authorization to an external HTTP service, or webhook. The webhook can implement custom logic for authorization and may integrate with services like Active Directory or LDAP. It sends back a response based on the authorization outcome.
• Kubernetes API Requests

  Admission Controllers: After authentication and authorization. These controllers perform checks on the API request to determine if it should proceed. There are two types of admission controllers:

  • Validating: These controllers check if the request is permitted and if it adheres to specific rules or policies. They ensure that actions do not breach any predefined checks.
  • Mutating: These controllers modify the request as needed. For example, when creating a pod, a mutating controller might alter the pod’s name to comply with a custom naming convention.
• Kubernetes API Requests

  Admission Controllers:

  • In addition to built-in admission controllers, Kubernetes allows the definition of custom checks to address specific needs.
  • These controllers are triggered after the request has passed authentication and authorization stages. Only if all admission controller checks are successful will the request be processed and persisted.
  • In summary, admission controllers are crucial for enforcing policies and making necessary modifications to requests before they are executed.
• K8s Security Best Practices

  Image Scanning:

  • The purpose of Kubernetes is to deploy applications, which are packaged into images. These images include all necessary components for running the app but also may contain security vulnerabilities due to their construction.
  • Image scanning is a technique used to identify potential security issues within these images.
• Image Scanning:

  Images consist of layers built from commands that create directories, users, and install tools or libraries. The security implications of these components include:

  • Untrusted Sources: Tools, libraries, or code within the image may come from untrusted sources, potentially introducing backdoors that could be exploited by attackers.
  • Official Images: While official container images (e.g., Nginx for web applications, or Postgres for database applications) are often considered safe, they can still contain vulnerabilities. Non-official or outdated images also pose security risks.
• Image Scanning

  To mitigate these risks, it's a best practice to minimize the attack surface of your images. This involves:

  • Using only the libraries and components necessary for the application.
  • Selecting the most lightweight and secure base image appropriate for the application’s needs.

  Vulnerabilities in application images can have serious consequences, such as allowing attackers to exploit weaknesses to break out of containers, access the host system, and gain critical cluster information like kubelet API authentication certificates or tokens. This could lead to a major security incident.
• Image Scanning Tools:

  • Tools like Snyk can scan images for vulnerabilities against a database and identify issues such as hard-coded secrets. Integrating image scanning into your CI/CD pipeline is essential to ensure that only secure images are deployed into your Kubernetes cluster, enhancing overall security.