You are viewing documentation for version 1.22.x. The most current version is 1.26.x.  This documentation is available for 1.26.x.

Shell-less Host

Using Linux without a shell

Bottlerocket images do not have an SSH server nor even a shell. As it turns out, you don’t need one in the host operating system itself. Bottlerocket does, however, give you out-of-band access that allows you to launch a shell from a container to explore, debug, manually update, and change settings on the host.

Host container out-of-band access

Since the software doesn’t exist on the host to facilitate interactive shell sessions, it is provided through a container. These containers are granted access to resources on the underlying host, have the required software for remote connections, and are run in the host containerd instance.

Control container

The control container’s purpose is to provide a first-tier host access where you can make API calls and gain access to some host-level resources. For aws-k8s-* and aws-ecs-* variants, the control container is on by default and remote connections are made through AWS SSM.

The control container is also the path to enable or enter the admin container.

Admin container

The admin container is designed to provide out-of-band access with elevated privileges. On aws-k8s-* and aws-ecs-* variants, the admin container is not enabled by default but can be turned on or entered through the control container. The best security practice is to disable the admin container and only enable it as-needed.

The admin container has a mount to the host file system1, an unrestricted SELinux label as well as all of the capabilities of the control container. Using the admin container should be rare: only used as-needed and by those required.

With kubectl on Kubernetes

For variants designed to be used with Kubernetes, you can gain out-of-band access to a node by using kubectl exec and a pod spec with specific volume mounts and security contexts. You can read more about this method in Regaining Access to a Bottlerocket Node. This method is very similar to running the control container, but it runs in the orchestrated containerd instance instead of the host containerd instance.


See a problem with this page? File an issue. All feedback is appreciated.
You can also directly contribute a change to the source file of this page on GitHub.

  1. The admin container mount for the host file system is located at /.bottlerocket/rootfs/. Despite the use of rootfs in the path, this mount has both immutable and mutable directories. ↩︎