Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docs: add lockdown notes to SECURITY_GUIDANCE.md #1281

Merged
merged 1 commit into from
Feb 11, 2021
Merged

docs: add lockdown notes to SECURITY_GUIDANCE.md #1281

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 28 additions & 0 deletions SECURITY_GUIDANCE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,7 @@ We provide these recommendations, along with [details](#details) and [examples](
| [Restrict access to the host API socket](#restrict-access-to-the-host-api-socket) | Critical |
| [Restrict access to the container runtime socket](#restrict-access-to-the-container-runtime-socket) | Critical |
| [Design for host replacement](#design-for-host-replacement) | Important |
| [Enable kernel lockdown](#enable-kernel-lockdown) | Important |
| [Limit use of host containers](#limit-use-of-host-containers) | Important |
| [Limit use of privileged SELinux labels](#limit-use-of-privileged-selinux-labels) | Important |
| [Limit access to system mounts](#limit-access-to-system-mounts) | Important |
Expand Down Expand Up @@ -104,6 +105,28 @@ If the kernel is ever compromised through a local exploit, then other defenses m

We recommend designing for periodic host replacement even with automated updates enabled.

### Enable kernel lockdown

The security mechanisms in Bottlerocket ultimately depend on the kernel for enforcement.
This includes access controls such as capabilities and SELinux, and integrity checks such as dm-verity.
Modifications to the running kernel could bypass or subvert these mechanisms.

Bottlerocket enables the Lockdown security module and offers settings to choose from one of three modes.

The first mode, "none", effectively disables the protection.
This is the default in today's [variants](variants/) of Bottlerocket, for compatibility with existing deployments.
Comment on lines +116 to +117
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you expect the default to change for some variants? I see it as more of a global Bottlerocket security offering.

Copy link
Contributor Author

@bcressey bcressey Jan 14, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could change the default for new launches but migrate to "none" on upgrade, which might be the current behavior.

Today we have the property that you can continue launching new versions of the same variant with no user-data changes. I worry about discarding that property; we don't want moving to new versions to become a scary proposition.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd worry about anything where we change behavior for new launches as compared to upgrades because it introduces a risk for drift within a customer's cluster. For example, if a customer operates an auto-scaling group and changes the ASG to launch a new AMI while upgrading the existing instances, some will have "none" (the upgraded ones) while others won't.


The second mode, "integrity", blocks most ways to overwrite the kernel's memory and modify its code.
This will become the default in future variants.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar question here - some variants are longer-lived, like aws-ecs-1, and I believe we should aim for changing the setting for existing variants rather than segmenting our security story by variant.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For aws-ecs-1, I'd like to change the default prior to GA.

The aws-k8s-* variants will age out of support over the next year, so making the changes in newer variants would let us converge on the new default without risk of disruption.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm 👍 on changing the default for aws-ecs-1 prior to GA. I'm also 👍 on introducing this to the new aws-k8s-* variants as we add them.

Enabling this mode will prevent unsigned kernel modules from being loaded.

The third mode, "confidentiality", stops most ways of reading the kernel's memory from userspace.
The goal is to protect secrets that may be stored in the kernel, such as keys used to detect modification while the system is offline.
Bottlerocket does not make use of the secrets that this mode is meant to protect.
Enabling this mode will break BPF, perf, and any other tools that rely on reading kernel memory.

We recommend enabling kernel lockdown in "integrity" mode.

### Limit use of host containers

Bottlerocket offers host containers to provide out-of-band access to the underlying host OS.
Expand Down Expand Up @@ -223,6 +246,11 @@ These settings can passed as [user data](https://docs.aws.amazon.com/AWSEC2/late
They apply to any Bottlerocket variant.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this comment still apply if you're talking about segmenting this setting's default by variant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a correct statement today, and would be a no-op if we change the default.


```
# Enable kernel lockdown in "integrity" mode.
# This prevents modifications to the running kernel, even by privileged users.
[settings.kernel]
lockdown = "integrity"

# The admin host container provides SSH access and runs with "superpowers".
# It is disabled by default, but can be disabled explicitly.
[settings.host-containers.admin]
Expand Down