docs: add a guide to run OpenShell sandboxes with Kata runtime - #9
docs: add a guide to run OpenShell sandboxes with Kata runtime#9rh-dnagornuks wants to merge 1 commit into
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdded an OpenShift guide for running OpenShell sandboxes with the Kata runtime. The guide covers gateway configuration, runtime selection, VM isolation verification, binary-aware network policy checks, security boundaries, limitations, troubleshooting, and cleanup. The README links to the guide. Two privileged DaemonSets patch Kata initramfs images with Estimated code review effort: 4 (Complex) | ~45 minutes 🚥 Pre-merge checks | ✅ 9 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (9 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@guides/openshell-with-osc.md`:
- Line 17: Update both ADDITIONAL RESOURCES headings in the documentation to use
level-three Markdown headings with the exact text “Additional resources,”
replacing the current level-five bold headings.
- Line 136: Update the prose in the step description to use the official product
name “GitHub,” while preserving the lowercase `github.com` hostname in the
command or URL.
- Around line 122-124: Update the network probes in the guide: add both connect
and total-operation timeouts to the curl checks, and pass a timeout argument to
the python3 probe’s urllib.request.urlopen call. Apply these changes to the
probes at the referenced locations while preserving their existing
connectivity-check behavior.
- Around line 211-217: Update the cleanup instructions near the Helm uninstall
commands to remove only the Kubernetes manifest cleanup identified as cwe-686,
replacing “oc delete ns openshell” with explicit deletion of the demo resources
created by this guide. Add a warning that namespace deletion is appropriate only
on a disposable cluster, and retain cleanup of the gateway configuration and SCC
access.
- Around line 41-46: Update both documented Helm upgrade commands around the
visible supervisor.topology and server.defaultRuntimeClassName settings to pin
the tested OpenShell chart using an explicit version or immutable OCI digest
instead of the unversioned chart reference, and record the corresponding tested
OpenShell version in the procedure.
- Around line 41-46: Update both Helm upgrade commands in the guide to
explicitly target the openshell namespace by adding the --namespace openshell
option, including the commands near the supervisor topology configuration and
the later upgrade command. Leave the remaining upgrade options unchanged.
- Around line 120-132: Update the external-endpoint verification section after
the curl command to require checking openshell logs for a DENIED audit event
matching github.com:443 and the calling binary, using the kata-demo sandbox log
command, before claiming OpenShell enforced the policy; otherwise describe the
403 only as an observed failure without attributing its cause.
- Around line 162-172: Update the “Security model” section and table to document
that enabling supervisor.sidecar.processBinaryAwareNetworkPolicy runs the
network sidecar as UID 0 with SYS_PTRACE and DAC_READ_SEARCH for cross-UID
inspection. Also state the security trade-off that disabling
processBinaryAwareNetworkPolicy removes these privileged requirements but
disables binary-aware matching, alongside the existing restricted
agent-container description.
- Around line 99-112: Update the kernel inspection guidance to state that
differing host and sandbox uname -r values indicate a guest kernel, but matching
releases are inconclusive and must not prove a VM boundary. Preserve the runtime
class check and direct readers to provider-supported Kata isolation verification
before asserting VM-based isolation.
- Around line 52-58: Update the gateway readiness instructions around the `oc
get pods -n openshell` step to have users wait for the pod’s `Ready` condition,
not merely phase `Running`, before executing `openshell sandbox create`. Include
an appropriate readiness check and retain the sequencing requirement that
sandboxes are created only after the gateway is ready.
- Around line 13-20: Update the prerequisites in the OpenShell with OSC guide to
distinguish the nested `kata` and `kata-remote` paths: retain the existing
`RuntimeClass` requirement for nested Kata, and require operator-verified
provider Secret, `peer-pods-cm`, `KataConfig`, and completed peer-pod VM image
readiness before sandbox creation when using peer pods.
- Around line 32-34: Update the KATA_RUNTIMECLASS guidance to state that
bare-metal deployments use kata, without attributing this to nested
virtualization. Keep kata-remote for peer pod deployments, including ROSA.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: ddf9f120-952b-4987-8638-867423ac8eea
📒 Files selected for processing (2)
README.mdguides/openshell-with-osc.md
1472fb8 to
10fcc0d
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
guides/openshell-with-osc.md (1)
43-43: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueExtract the pinned chart version into a single reusable value.
--version 0.0.85is repeated in twohelm upgradeinvocations (Line 43 and Line 208). If the tested chart version changes, both occurrences must be updated in lockstep or the guide silently regresses to an untested Helm chart version in one of the two flows.Also applies to: 208-208
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@guides/openshell-with-osc.md` at line 43, Define the pinned Helm chart version once in a reusable value and reference it from both helm upgrade invocations at the documented locations, removing the duplicated literal while preserving the current version and command behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@guides/openshell-with-osc.md`:
- Line 43: Define the pinned Helm chart version once in a reusable value and
reference it from both helm upgrade invocations at the documented locations,
removing the duplicated literal while preserving the current version and command
behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 82171571-748d-4366-a93d-71085240c097
📒 Files selected for processing (2)
README.mdguides/openshell-with-osc.md
🚧 Files skipped from review as they are similar to previous changes (1)
- README.md
10fcc0d to
0b3083a
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/kata-nftables-patch-job.yaml`:
- Line 146: Preserve the first pre-patch initramfs backup across both patch
jobs: in scripts/kata-nftables-patch-job.yaml lines 146-146, create
${INITRD}.bak only when it does not already exist; in
scripts/kata-veth-patch-job.yaml lines 103-103, likewise avoid overwriting an
existing backup. Keep the existing patch flow unchanged after the backup step.
- Around line 31-39: Add a dedicated ServiceAccount and grant it privileged SCC
access before applying both DaemonSets:
scripts/kata-nftables-patch-job.yaml:31-39 and
scripts/kata-veth-patch-job.yaml:31-39. Set each DaemonSet’s
spec.serviceAccountName to that account, or use a narrowly scoped custom SCC and
document the policy update; preserve the existing privileged container, hostPID,
and hostPath requirements.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: cd058e62-7364-4c0e-b64f-e49b9724550d
📒 Files selected for processing (4)
README.mdguides/openshell-with-osc.mdscripts/kata-nftables-patch-job.yamlscripts/kata-veth-patch-job.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- README.md
0b3083a to
7b5baa1
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/kata-nftables-patch-job.yaml`:
- Line 42: Replace the mutable :latest tag with the reviewed immutable UBI image
digest at scripts/kata-nftables-patch-job.yaml:42-42 and
scripts/kata-veth-patch-job.yaml:42-42, using the identical digest in both
privileged patcher job definitions.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: cbb95bd7-ae87-4d51-a571-bc6faefd29f1
📒 Files selected for processing (4)
README.mdguides/openshell-with-osc.mdscripts/kata-nftables-patch-job.yamlscripts/kata-veth-patch-job.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- README.md
f7da96c to
4d3232e
Compare
|
Tested this on the shared cluster (agent-ops, 4.19.40). Everything works. Nice work. Kata-remote sandbox spins up, egress blocked by default, binary-aware policy works as expected (curl gets through, python doesn't). |
4d3232e to
32ec401
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/kata-nftables-patch-job.yaml`:
- Around line 68-72: Update the “Check if already patched” logic in the
initramfs patch job to run after the MODULES list is defined, and skip only when
every module in MODULES is present in INITRD. Remove the single nf_tables-only
check while preserving the existing skip message and successful exit behavior.
- Around line 107-152: The initramfs read-modify-write operations are not
serialized, allowing concurrent patch jobs to overwrite each other. In
scripts/kata-nftables-patch-job.yaml lines 107-152, acquire the shared
host-level lock before the no-op check and hold it through the final mv; apply
the same lock scope to scripts/kata-veth-patch-job.yaml lines 81-108, using the
identical shared lock, so both patch flows protect the complete operation.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 9519962a-124d-4c60-84e7-c5d1a2a22387
📒 Files selected for processing (3)
guides/openshell-with-osc.mdscripts/kata-nftables-patch-job.yamlscripts/kata-veth-patch-job.yaml
a2c0bc4 to
b7d67b0
Compare
| Perform the following steps: | ||
|
|
||
| 1. Update the gateway to use Kata. | ||
| 2. Optional: Patch the Kata initramfs. |
There was a problem hiding this comment.
The initramfs patch doesn't appear to be optional for users who select kata. The section says that sandbox creation fails without nf_tables and that only kata-remote users can skip the patch. Could we change the step summary to something like “Patch the Kata initramfs if you use the kata runtime class”? That would make the conditional requirement clear before users start the procedure.
| oc debug node/"${NODE_NAME}" -- chroot /host cat /sys/class/dmi/id/sys_vendor /sys/class/dmi/id/product_name | ||
| ``` | ||
|
|
||
| On bare-metal clusters, the host reports the physical hardware vendor (for example, `Equinix` or `Dell Inc.`), while the sandbox reports `QEMU`. On peer pod deployments, both the host and the sandbox may report cloud provider values, but the sandbox product name reflects the peer pod instance type from the `peer-pods-cm` ConfigMap. |
There was a problem hiding this comment.
The bare-metal DMI examples seem inconsistent. The example output shows Red Hat / KVM, but the explanatory text later says that the sandbox reports QEMU. Could we reconcile these examples, or avoid prescribing an exact DMI value? Since these checks are supplementary diagnostics, it might be safer to say that the values should reflect the guest/hypervisor environment and differ from the physical host where applicable.
| > | ||
| > Treat the OpenShift installation path as experimental. Do not use it in production. | ||
|
|
||
| This guide builds on [Getting Started with OpenShell on OpenShift](getting-started-openshell-openshift.md). It configures new sandboxes to use a Kata-backed `RuntimeClass`, sets OpenShell to use `sidecar` topology, and shows how to verify the virtual machine (VM) boundary and OpenShell policy enforcement. By the end of this guide, you can run a Kata-backed sandbox and verify how this topology applies runtime and network controls. |
There was a problem hiding this comment.
"sets" could be changed to "configures"
| > | ||
| > Treat the OpenShift installation path as experimental. Do not use it in production. | ||
|
|
||
| This guide builds on [Getting Started with OpenShell on OpenShift](getting-started-openshell-openshift.md). It configures new sandboxes to use a Kata-backed `RuntimeClass`, sets OpenShell to use `sidecar` topology, and shows how to verify the virtual machine (VM) boundary and OpenShell policy enforcement. By the end of this guide, you can run a Kata-backed sandbox and verify how this topology applies runtime and network controls. |
There was a problem hiding this comment.
I'd change to:
Configure the gateway to use the sidecar topology and binary-aware network policy.
| KATA_RUNTIMECLASS=<runtime-class-name> | ||
| ``` | ||
|
|
||
| 2. Update OpenShell Helm chart to set the runtime class, sidecar topology, and binary-aware network policy: |
| ## Prerequisites | ||
|
|
||
| - You have completed [Getting Started with OpenShell on OpenShift](getting-started-openshell-openshift.md) through **Status Check**. | ||
| - You have installed the OpenShift Sandboxed Containers operator on the cluster. |
There was a problem hiding this comment.
Red Hat uses OpenShift sandboxed containers Operator:
lowercase sandboxed containers, uppercase Operator.
|
|
||
| ### Procedure | ||
|
|
||
| 1. Grant the `kata-install` service account privileged access. The patch DaemonSet runs privileged containers with host filesystem access. On bare-metal clusters, the operator does not create the required SCC automatically: |
There was a problem hiding this comment.
Kubernetes Operators have an uppercase "O" when referred to in prose.
| - **The sandbox pod does not use Kata.** Confirm that the runtime class name in `server.defaultRuntimeClassName` or `runtime_class_name` exactly matches one of the values returned by `oc get runtimeclass`, and then recreate the sandbox. | ||
| - **`python3` is allowed after the `curl` policy update.** Verify that `supervisor.sidecar.processBinaryAwareNetworkPolicy=true`. Setting it to `false` downgrades `sidecar` network policy to endpoint and L7 matching only. | ||
| - **The gateway pod does not recover after the Helm upgrade.** Check `oc get pods -n openshell` and confirm that the Helm values still include the Route hostname, `sidecar` topology, and the expected runtime class setting. | ||
| - **No Kata runtime class is available.** Wait for the OpenShift Sandboxed Containers rollout to finish, or verify that the operator and `KataConfig` are installed correctly. |
There was a problem hiding this comment.
Same comment here. Uppercase "O" in Operator.
| 4. Optional: Verify the VM isolation boundary. | ||
| 5. Verify policy enforcement in the Kata-backed sandbox. | ||
|
|
||
| Unless noted otherwise, run commands on your local machine. |
There was a problem hiding this comment.
This sentence could be made less awkward:
Run all commands on your local machine unless otherwise specified.
|
|
||
| ## Prerequisites | ||
|
|
||
| - You have completed [Getting Started with OpenShell on OpenShift](getting-started-openshell-openshift.md) through **Status Check**. |
There was a problem hiding this comment.
I’d use:
You have completed the steps through and including the Status Check section in Getting Started with OpenShell on OpenShift.
If Status Check is the final required section, an even cleaner option is:
You have completed the Getting Started with OpenShell on OpenShift guide through the Status Check section.
|
|
||
| > **Important** | ||
| > | ||
| > This patch does not survive node reboots. The `kata-osbuilder-generate` service regenerates the initramfs from the unpatched dracut configuration on boot. Go through the procedure again after any worker node reboot or `KataConfig` change that triggers a node rollout. |
There was a problem hiding this comment.
Make the consequence and required action more direct
Important
The patch is removed when a worker node reboots because the kata-osbuilder-generate service regenerates the initramfs from the unpatched dracut configuration. Reapply the patch after a worker node reboot or after a KataConfig change that causes the worker nodes to roll out.
|
|
||
| ## 3. Create a Kata-backed sandbox | ||
|
|
||
| Create a sandbox after the gateway upgrade. |
There was a problem hiding this comment.
The current text is too thin because it does not connect the task back to the runtime-class choice made earlier. Enhance:
- Create a Kata-backed sandbox
Create a sandbox that uses the Kata runtime class that you configured earlier. You can use the gateway-wide default runtime class or specify the runtime class when you create the sandbox.
|
|
||
| ### Procedure | ||
|
|
||
| Run the command sequence that matches your setup: |
There was a problem hiding this comment.
"your setup" is unclear. This could be made more consise:
Run the command that matches how you configured the runtime class.
|
|
||
| Run the command sequence that matches your setup: | ||
|
|
||
| If you configured a gateway-wide default runtime class, run: |
There was a problem hiding this comment.
Use full and complete sentences when introducing commands:
If you configured a gateway-wide default runtime class, create the sandbox by running the following command:
| openshell sandbox create --name kata-demo -- sleep 1 | ||
| ``` | ||
|
|
||
| If you want to override the runtime class for this sandbox only, run: |
There was a problem hiding this comment.
Same comment here. Use full and complete sentences when introducing commands:
If you want to override the gateway default and specify the runtime class for this sandbox only, run the following command:
| The per-sandbox `runtime_class_name` value overrides the gateway default for this sandbox. | ||
|
|
||
| ### Verification | ||
|
|
There was a problem hiding this comment.
The Verification section only seems to have one step. If so, the step number can be removed.
There was a problem hiding this comment.
Does this doc need to be changed as well? https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.13/html/deploying_openshift_sandboxed_containers_on_aws/configure-osc-overview_aws-osc#creating-peer-pods-cm_aws-osc
That also has a step number for a single step
There was a problem hiding this comment.
@rh-dnagornuks that's a fair point.
They could probably remove that step there too.
|
|
||
| ### Verification | ||
|
|
||
| 1. Verify that Kubernetes assigned the Kata runtime class: |
There was a problem hiding this comment.
Make the expected result more explicit and tie it directly to the verification goal:
Verify that the sandbox pod is configured to use the expected Kata runtime class by running the following command:
The command returns the runtime class assigned to the sandbox pod. Verify that the output is kata for deployments that use nested virtualization or kata-remote for deployments that use peer pods.
|
|
||
| ## 4. Verify the VM isolation boundary | ||
|
|
||
| The RuntimeClass check in section 3 is the authoritative verification. When a pod runs with `runtimeClassName: kata` or `kata-remote`, the CRI-O Kata handler (`runtime_type = "vm"`) guarantees that the workload runs inside a dedicated virtual machine. |
There was a problem hiding this comment.
Let's soften this slightly and also make the relationship between the two checks clearer:
Verify the VM isolation boundary
The runtime class verification in section 3 confirms that the sandbox pod is configured to use the kata or kata-remote runtime. OpenShift Sandboxed Containers uses the Kata runtime to run the workload in a dedicated virtual machine (VM).
You can perform the following DMI checks to gather additional information about the VM environment and confirm that it uses the expected hypervisor. These checks provide supplementary diagnostic information and are not required to verify that the sandbox is configured to use Kata.
|
|
||
| The DMI checks below are supplementary diagnostic evidence. They can help confirm that the VM is backed by the expected hypervisor, but they do not independently prove or disprove Kata isolation. | ||
|
|
||
| 1. Check the system vendor and product name inside the sandbox: |
There was a problem hiding this comment.
Make this more concise emphasizing the purpose of the step:
Verify that the sandbox is running in the expected virtual machine environment by checking the system vendor and product name:
| KVM | ||
| ``` | ||
|
|
||
| 2. Compare with the host node: |
There was a problem hiding this comment.
Enhance this step to make both the action and what the reader should compare more explicit:
Compare the sandbox VM information with the host node by running the following commands:
Compare the host output with the values returned from the sandbox in the previous step. On bare-metal clusters, the host typically reports the physical hardware vendor, such as Dell Inc., while the sandbox reports values associated with the virtualized guest environment.
On peer pod deployments, both environments might report cloud-provider information, but the sandbox product name should reflect the peer pod instance type configured in the peer-pods-cm ConfigMap.
|
|
||
| ### Confirm that network egress is blocked by default | ||
|
|
||
| 1. Connect to the sandbox: |
There was a problem hiding this comment.
State the sandbox name that you are referring to.
Connect to the kata-demo sandbox by running the following command:
| openshell sandbox connect kata-demo | ||
| ``` | ||
|
|
||
| 2. Attempt to reach an external endpoint from the sandbox shell: |
There was a problem hiding this comment.
Add some context here:
From the sandbox shell, verify that outbound network access is blocked by attempting to connect to GitHub:
|
|
||
| This result shows that sandbox egress still flows through the OpenShell network policy path. Running the pod behind Kata does not bypass policy enforcement. | ||
|
|
||
| ### Allow one binary and keep the rest blocked |
There was a problem hiding this comment.
Make the overall goal clearer here:
Allow network access for one binary
|
|
||
| ### Allow one binary and keep the rest blocked | ||
|
|
||
| 1. From your local machine, allow only `/usr/bin/curl` to reach GitHub: |
There was a problem hiding this comment.
Make the purpose of the step clearer:
From your local machine, update the sandbox policy to allow only /usr/bin/curl to connect to GitHub:
| --wait | ||
| ``` | ||
|
|
||
| 2. From inside the sandbox shell, test again: |
There was a problem hiding this comment.
Use complete sentences for commands. Be clear about the purpose of the step:
From the sandbox shell, verify that the policy allows curl but continues to block other binaries by running the following commands:
|
|
||
| `curl` should succeed, while `python3` should still fail with a tunnel connection failure. This result confirms that the sidecar still matches on binary identity, not only on destination. | ||
|
|
||
| 3. To watch the corresponding audit events, open the OpenShell terminal from your local machine: |
There was a problem hiding this comment.
Make more concise:
From your local machine, open the OpenShell terminal to view the corresponding network audit events:
| openshell term | ||
| ``` | ||
|
|
||
| 4. Select `kata-demo` and switch to the live log view with the `l` key. You should see `DENIED` and `ALLOWED` network events for the same destination, depending on which binary made the request. |
There was a problem hiding this comment.
Avoid using the word "should" when possible:
Select kata-demo, and then press l to open the live log view. Verify that the log shows ALLOWED events for requests from /usr/bin/curl and DENIED events for requests from python3 to the same destination.
| ## Security model | ||
|
|
||
| OpenShell `sidecar` topology and a Kata `RuntimeClass` apply controls at different layers. OpenShell focuses on workload egress policy. Kata runs the pod inside a guest virtual machine. | ||
|
|
There was a problem hiding this comment.
OpenShell enforces network policy for sandbox workloads, while Kata provides an additional isolation boundary by running the pod inside a guest virtual machine (VM).
|
|
||
| OpenShell `sidecar` topology and a Kata `RuntimeClass` apply controls at different layers. OpenShell focuses on workload egress policy. Kata runs the pod inside a guest virtual machine. | ||
|
|
||
| `combined` topology also enforces OpenShell network policy, but `sidecar` moves that enforcement into a dedicated sidecar so the long-running agent container can run without added Linux capabilities. |
|
|
||
| - In `sidecar` topology, OpenShell does not run the full enforcement path. The process supervisor runs in `network-only` mode. OpenShell still enforces network policy through the sidecar, and Landlock filesystem policy plus child seccomp filters still apply where supported. However, root-to-sandbox privilege dropping and supervisor identity mount isolation do not run in the agent container. | ||
| - `gVisor` is not supported with `sidecar` topology because sidecar mode requires pod-local `nftables` setup in the init container. | ||
| - Kata adds a guest virtual machine boundary, but it does not restore the controls that `sidecar` mode relaxes compared with `combined` topology. |
There was a problem hiding this comment.
Avoid using the word "relaxes":
Kata adds a guest virtual machine boundary, but it does not replace the additional controls provided by combined topology.
|
|
||
| ## Cleanup | ||
|
|
||
| Delete the demo sandboxes when you finish: |
There was a problem hiding this comment.
In the cleanup section, numbered steps have not been used. Previously, numbered steps were used. Make consistent.
| - **The gateway pod does not recover after the Helm upgrade.** Check `oc get pods -n openshell` and confirm that the Helm values still include the Route hostname, `sidecar` topology, and the expected runtime class setting. | ||
| - **No Kata runtime class is available.** Wait for the OpenShift Sandboxed Containers rollout to finish, or verify that the operator and `KataConfig` are installed correctly. | ||
|
|
||
| ## Cleanup |
There was a problem hiding this comment.
Make the cleanup paths explicit, because there are really two different goals here: remove only the test sandbox, or completely remove OpenShell.
|
|
||
| ## Cleanup | ||
|
|
||
| Delete the demo sandboxes when you finish: |
There was a problem hiding this comment.
For completeness, state what demo sandboxes you are referring to:
To remove the kata-demo sandbox, run the following command:
| openshell sandbox delete kata-demo | ||
| ``` | ||
|
|
||
| Revert the gateway to the earlier getting-started configuration: |
There was a problem hiding this comment.
If you want to keep OpenShell installed but return the gateway to the configuration used in the getting-started guide, run the following command:
| --set server.defaultRuntimeClassName="" | ||
| ``` | ||
|
|
||
| To remove the gateway and all other OpenShell resources, run: |
There was a problem hiding this comment.
If you no longer need the OpenShell installation, remove the gateway and associated resources by running the following commands:
chtyler
left a comment
chtyler
left a comment
There was a problem hiding this comment.
Comments added on prose, style and document structure.
Add a markdown file with instructions on running OpenShell sandboxes with Kata and a section explaining the security model Add manifests to enable Kata usage for OpenShell on bare-metal/nested virtualization Signed-off-by: Daniels Nagornuks <dnagornu@redhat.com>
b7d67b0 to
66dfe65
Compare
|
@chtyler Thank you for the review. I updated the guide with your feedback. I also responded to the comment on initramfs in the overview of steps. Let me know if I something needs changing or if it's good to merge. |
3 participants
Description
This PR adds a guide for running OpenShell sandboxes with Kata runtime. It builds on top of parts from
guides/getting-started-openshell-openshift.mdand links prerequisite material for installing OpenShift Sandboxed Containers operator (which provides Kata, a runtime that runs sandboxes as virtual machines rather than as containers). The guide also covers the egress policy enforcement and OpenShell topology modes.This PR also adds DaemonSet manifests to patch bare-metal cluster nodes to include kernel modules needed for either topology mode (combined/sidecar), with reference to the manifest for sidecar enablement within the guide markdown.
Relevant Jira issue: RHAIENG-6386
Testing
Merge criteria
Summary by CodeRabbit
Documentation
New Features