> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Run shell untrusted

### Event Information

#### Meaning

* The "Run shell untrusted" event in a Kubernetes cluster indicates that a shell command was executed within a container running in the cluster, and it was flagged as untrusted.
* This event typically occurs when a user or process attempts to run a shell command that is not allowed or violates the security policies defined for the cluster.
* It is important to investigate this event further to determine the source of the command and assess whether it poses a security risk or violates any compliance standards.

To investigate further, you can:

* Use the `kubectl get pods` command to identify the pod in which the event occurred.
* Use the `kubectl logs <pod-name>` command to view the logs of the container and look for any suspicious or unauthorized shell commands.
* Review the security policies and access controls in place to ensure that only trusted and authorized commands are allowed to be executed within the cluster.

#### Remediation

1. Update Security Policies:
   * Use Security Context Constraints (SCC) or Pod Security Policies (PSP) Alternatives.

   * Since PodSecurityPolicy is deprecated, consider using alternative solutions like Kubernetes PodSecurityAdmission or OPA/Gatekeeper  to enforce security policies.

   * Kubernetes PodSecurityAdmission (PSA) provides a built-in way to enforce security policies. Here’s an example of how to enforce security controls using PSA:
   ```yaml theme={null}
   apiVersion: policy/v1
   kind: PodSecurityPolicy
   metadata:
     name: restricted
   spec:
     privileged: false
     allowPrivilegeEscalation: false
     allowedCapabilities: []
     volumes:
       - 'emptyDir'
       - 'configMap'
       - 'projected'
       - 'secret'
     hostNetwork: false
     hostIPC: false
     hostPID: false
     runAsUser:
       rule: 'MustRunAsNonRoot'
     seLinux:
       rule: 'Must'
     supplementalGroups:
       rule: 'MustNot'
     fsGroup:
       rule: 'MustNot'
     readOnlyRootFilesystem: true
   ```
   * Implement OPA/Gatekeeper Policies Open Policy Agent (OPA) and Gatekeeper can be used to enforce custom policies. For example, you can create a policy that restricts the execution of untrusted shell commands:
   ```yaml theme={null}
   apiVersion: constraints.gatekeeper.sh/v1beta1
   kind: K8sSecurityContextConstraints
   metadata:
     name: restrict-shell-commands
   spec:
     enforcementAction: deny
     match:
       kinds:
         - apiGroups: [""]
           kinds: [Pod]
     parameters:
       securityContext:
         runAsNonRoot: true
         allowPrivilegeEscalation: false
         capabilities:
           drop:
             - ALL
   ```

2. Update Deployment or Pod Specifications:
   * Ensure that new pods adhere to the updated security policies by modifying their configurations:
   ```yaml theme={null}
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: your-deployment
    spec:
      template:
        spec:
          securityContext:
            runAsNonRoot: true
            readOnlyRootFilesystem: true
          containers:
          - name: your-container
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop:
                  - ALL
   ```

3. Apply the updated security policies and configurations to your cluster:

```bash theme={null}
     kubectl apply -f <policy-file.yaml>
     kubectl apply -f <deployment-file.yaml>
```

Note: Make sure to test all changes in a staging environment before applying them to production to avoid any unintended disruptions.