**Help improve this page** 

To contribute to this user guide, choose the **Edit this page on GitHub** link that is located in the right pane of every page.

# Observability
<a name="sandboxing-observability"></a>

Running a pod inside a Nitro Sandbox changes what you can observe and how. What you can see depends on the pod’s mode, because the Cedar policy controls which operations the parent instance can perform.

## Logs and exec
<a name="sandboxing-observability-logs-exec"></a>

 `kubectl logs` works for sandboxed pods in both isolated and confidential mode. Container logs stream over the vsock channel to the parent instance. The container’s termination message and container stats (`kubectl top`) are also available by default in both modes.

 `kubectl exec` (along with `kubectl attach`, `stdin`, and process listing) depends on the mode:
+  **Isolated mode** permits `exec`, `stdin`, and process listing, so interactive debugging works the same as for a standard pod.
+  **Confidential mode** denies `exec`, `stdin`, and process listing by default, so the parent instance cannot introspect the guest. You can permit specific exec commands when you generate the Cedar policy. For more information, see [Run a pod in confidential mode](sandboxing-confidential-setup.md).

## Node-level monitoring agents
<a name="sandboxing-observability-agents"></a>

Monitoring agents that run on the node cannot observe activity inside a Nitro Sandbox, because the sandbox isolates the pod from the node. This includes the Amazon CloudWatch Observability agent and the Amazon GuardDuty agent. Both continue to monitor standard pods and node-level activity on the same node. For more information, see [Monitor cluster data with Amazon CloudWatch](cloudwatch.md) and [Detect threats with Amazon GuardDuty](integration-guardduty.md).