Skip to main content

K8s Audit Log Role With Pod Exec

This alert occurs when Lacework detects the creation of a role that allows the ability to execute commands inside a pod, also called remote access to pods (kubectl exec).

Why this alert is important​

Attackers can potentially exploit the ability to execute commands inside a pod in various ways to carry out malicious activities. Here are some examples:

  • Shell commands:
    • rm: Remove files or directories
    • mv: Move or rename files or directories
    • cp: Copy files or directories
    • touch: Create a new file or update the timestamp of an existing file
    • chmod: Change file permissions
  • Networking commands:
    • ping: Send ICMP echo requests to a specified network host
    • nslookup: Perform DNS lookups to retrieve IP addresses or other DNS records
    • curl: Make HTTP/HTTPS requests to a specified URL
    • wget: Download files from the web
  • Process management commands:
    • kill: Send a signal to terminate a process
    • pgrep: List process IDs based on criteria
  • File manipulation and inspection commands:
    • grep: Search for a specific pattern in files or input
    • sed: Invoke stream editor for modifying text
    • awk: Text processing language for manipulating data and generating reports

Investigation​

Follow these steps to investigate the alert:

  1. Check the Kubernetes audit logs for relevant entries related to role creation or modification.
  2. Search for the specific Role and RoleBinding objects that allow command execution within pods. These objects are typically defined in the Kubernetes configuration files or through the Kubernetes API.
  3. Examine the configuration of the identified Role and RoleBinding objects. Pay attention to the associated users, groups, or service accounts that have been granted access permissions. Look for any suspicious or unauthorized entries.
  4. Analyze the logs or monitoring data for pod executions. Look for any unusual or unauthorized commands being executed inside the pods associated with the role. This can help identify potential malicious activities.
  5. Investigate the activity of the user or service account associated with the role creation. Check for abnormal access patterns, logins from unfamiliar locations, or other signs of compromise.
  6. Verify that the Role and RoleBinding objects adhere to the principle of least privilege. Cross-reference the assigned permissions with the actual requirements of the pods and applications. Ensure that unnecessary or excessive privileges are not granted.
  7. Consult the historical data or audit trail within your security monitoring or management systems. Look for any indications of unauthorized role creation or suspicious activities related to the role.

Resolution​

Follow these steps to resolve the alert:

  1. If the role was created maliciously or in error, remove it immediately to prevent further unauthorized access or activity.
  2. Change the credentials of any users who may have been involved in creating the unauthorized role, and revoke their access if necessary.
  3. Review all users' permissions and access levels and ensure they are appropriate for their job functions. Remove any excessive permissions that could lead to potential security breaches.
  4. Conduct a thorough security audit of the affected cluster to identify other security vulnerabilities or suspicious activity.
  5. Implement additional security measures such as multi-factor authentication, network segmentation, and regular security training for users to prevent future security incidents.