add description about debugging profile
parent
71c870d214
commit
0c8a63f4a2
|
@ -632,10 +632,89 @@ When creating a debugging session on a node, keep in mind that:
|
||||||
* The container runs in the host IPC, Network, and PID namespaces, although
|
* The container runs in the host IPC, Network, and PID namespaces, although
|
||||||
the pod isn't privileged, so reading some process information may fail,
|
the pod isn't privileged, so reading some process information may fail,
|
||||||
and `chroot /host` may fail.
|
and `chroot /host` may fail.
|
||||||
* If you need a privileged pod, create it manually.
|
* If you need a privileged pod, create it manually or use the `--profile=sysadmin` flag.
|
||||||
|
|
||||||
Don't forget to clean up the debugging Pod when you're finished with it:
|
Don't forget to clean up the debugging Pod when you're finished with it:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
kubectl delete pod node-debugger-mynode-pdx84
|
kubectl delete pod node-debugger-mynode-pdx84
|
||||||
```
|
```
|
||||||
|
|
||||||
|
## Debugging Profiles {#debugging-profiles}
|
||||||
|
|
||||||
|
When using `kubectl debug` to debug a node via a debugging Pod, a Pod via an ephemeral container,
|
||||||
|
or a copied Pod, you can apply a debugging profile to them using the `--profile` flag.
|
||||||
|
By applying a profile, specific properties such as [securityContext](/docs/tasks/configure-pod-container/security-context/)
|
||||||
|
are set, allowing for adaptation to various scenarios.
|
||||||
|
|
||||||
|
|
||||||
|
The available profiles are as follows:
|
||||||
|
|
||||||
|
| Profile | Description |
|
||||||
|
| ------------ | --------------------------------------------------------------- |
|
||||||
|
| legacy | A set of properties backwards compatibility with 1.22 behavior |
|
||||||
|
| general | A reasonable set of generic properties for each debugging journey |
|
||||||
|
| baseline | A set of properties compatible with [PodSecurityStandard baseline policy](/docs/concepts/security/pod-security-standards/#baseline) |
|
||||||
|
| restricted | A set of properties compatible with [PodSecurityStandard restricted policy](/docs/concepts/security/pod-security-standards/#restricted) |
|
||||||
|
| netadmin | A set of properties including Network Administrator privileges |
|
||||||
|
| sysadmin | A set of properties including System Administrator (root) privileges |
|
||||||
|
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
If you don't specify `--profile`, the `legacy` profile is used by default, but it is planned to be deprecated in the near future.
|
||||||
|
So it is recommended to use other profiles such as `general`.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
|
||||||
|
Assume that you create a Pod and debug it.
|
||||||
|
First, create a Pod named `myapp` as an example:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d
|
||||||
|
```
|
||||||
|
|
||||||
|
Then, debug the Pod using an ephemeral container.
|
||||||
|
If the ephemeral container needs to have privilege, you can use the `sysadmin` profile:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl debug -it myapp --image=busybox:1.28 --target=myapp --profile=sysadmin
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
Targeting container "myapp". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
|
||||||
|
Defaulting debug container name to debugger-6kg4x.
|
||||||
|
If you don't see a command prompt, try pressing enter.
|
||||||
|
/ #
|
||||||
|
```
|
||||||
|
|
||||||
|
Check the capabilities of the ephemeral container process by running the following command inside the container:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
/ # grep Cap /proc/$$/status
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
...
|
||||||
|
CapPrm: 000001ffffffffff
|
||||||
|
CapEff: 000001ffffffffff
|
||||||
|
...
|
||||||
|
```
|
||||||
|
|
||||||
|
This means the container process is granted full capabilities as a privileged container by applying `sysadmin` profile.
|
||||||
|
See more details about [capabilities](/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container).
|
||||||
|
|
||||||
|
You can also check that the ephemeral container was created as a privileged container:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl get pod myapp -o jsonpath='{.spec.ephemeralContainers[0].securityContext}'
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
{"privileged":true}
|
||||||
|
```
|
||||||
|
|
||||||
|
Clean up the Pod when you're finished with it:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl delete pod myapp
|
||||||
|
```
|
||||||
|
|
|
@ -75,7 +75,8 @@ When creating a debugging session on a Node, keep in mind that:
|
||||||
* Although the container runs in the host IPC, Network, and PID namespaces,
|
* Although the container runs in the host IPC, Network, and PID namespaces,
|
||||||
the pod isn't privileged. This means that reading some process information might fail
|
the pod isn't privileged. This means that reading some process information might fail
|
||||||
because access to that information is restricted to superusers. For example, `chroot /host` will fail.
|
because access to that information is restricted to superusers. For example, `chroot /host` will fail.
|
||||||
If you need a privileged pod, create it manually.
|
If you need a privileged pod, create it manually or use the `--profile=sysadmin` flag.
|
||||||
|
* By applying [Debugging Profiles](/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles), you can set specific properties such as [securityContext](/docs/tasks/configure-pod-container/security-context/) to a debugging Pod.
|
||||||
|
|
||||||
## {{% heading "cleanup" %}}
|
## {{% heading "cleanup" %}}
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue