Admin Container available by default, but doc says disabled

[landbaychrisburrell]

Hi

I'm just starting to experiment with Bottlerocket, so am spinning up some instances, with all the defaults, and I'm able to log on via SSM. The welcome shell says I can "enter-admin-container" - which I had presumed would have been disabled, as per docs. So I can I check my understanding:

• When the docs say "The admin container is disabled by default in Bottlerocket.", this simply means it's not running, rather than not being available when someone is in the host container?
• I'm guessing the security benefit here is less attack surface, in particular less running-privileged attack surface?

Is there a way to make it impossible for SSM uses to start the container? (or have i somehow misconfigured/not configured something?)

Cheers
Chris

[stmcginnis]

Hi @landbaychrisburrell - your understanding is correct. When it says it is not enabled by default, that means when the Bottlerocket node launches there will not be a running admin container. You would need to either change the configuration setting settings.host-containers.admin.enabled = true, or connect to the control container like you describe and either run enable-admin-container to just start the admin container, or enter-admin-container to start it if not running and connect.

There are some additional details for those settings here: https://bottlerocket.dev/en/os/1.16.x/api/settings/host-containers/

As far as your second bullet item - you are absolutely correct. With not running the admin container by default, there is less surface area and less workload running on the node. Typically you would leave that not running and only enable it if and when you need to perform some type of troubleshooting or if you needed to enable the ability to SSH to the node. In normal running operations, that shouldn't be needed, so it does not run by default.

As far as making impossible to start the container, I can think of a couple options to accomplish that, but nothing that is a default setting out of the box. You could create your own custom control container that does not include the enter-admin-container script. You would have full control (and responsibility) for what goes in to that control container, so that would give you a lot of control over making that behave the way you want it to.

A sort of hacky workaround (OK, very hacky workaround) other than that would be to create a minimal admin container that restricts what someone could do from the admin container. You could configure the setting to point to your own container image. If that were set to a locked down customized image, you could potentially restrict some things there. Or point to a non-existent image so attempting to start the admin container just fails to pull it. But if someone is able to access the control container, they would also be able to change that setting. So a custom control container is probably the more useful approach.

[landbaychrisburrell]

Thanks for the very prompt answers - all the above makes a lot of sense - and grateful for the 2 additional pointers.
Cheers
Chris