Skip to content

Update seccomp design doc to enable default seccomp profile #1963

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

Merged
merged 2 commits into from
Apr 5, 2018
Merged

Update seccomp design doc to enable default seccomp profile #1963

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
95c737f
Update seccomp design doc to add default profile
wangzhen127 Mar 22, 2018
fdffde3
update docker/default to runtime/default
wangzhen127 Mar 27, 2018
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
41 changes: 24 additions & 17 deletions contributors/design-proposals/node/seccomp.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,7 @@ This design should:
* be container-runtime agnostic
* allow use of custom profiles
* facilitate containerized applications that link directly to libseccomp
* enable a default seccomp profile for containers

## Use Cases

Expand All @@ -40,14 +41,16 @@ This design should:
unmediated by Kubernetes
4. As a user, I want to be able to use a custom seccomp profile and use
it with my containers
5. As a user and administrator I want kubernetes to apply a sane default
seccomp profile to containers unless I otherwise specify.

### Use Case: Administrator access control

Controlling access to seccomp profiles is a cluster administrator
concern. It should be possible for an administrator to control which users
have access to which profiles.

The [pod security policy](https://github.com/kubernetes/kubernetes/pull/7893)
The [Pod Security Policy](https://github.com/kubernetes/kubernetes/pull/7893)
API extension governs the ability of users to make requests that affect pod
and container security contexts. The proposed design should deal with
required changes to control access to new functionality.
Expand Down Expand Up @@ -101,9 +104,7 @@ implement a sandbox for user-provided code, such as

## Community Work

### Container runtime support for seccomp

#### Docker / opencontainers
### Docker / OCI

Docker supports the open container initiative's API for
seccomp, which is very close to the libseccomp API. It allows full
Expand All @@ -112,14 +113,21 @@ specification of seccomp filters, with arguments, operators, and actions.
Docker allows the specification of a single seccomp filter. There are
community requests for:

Issues:

* [docker/22109](https://github.com/docker/docker/issues/22109): composable
seccomp filters
* [docker/21105](https://github.com/docker/docker/issues/22105): custom
seccomp filters for builds

#### rkt / appcontainers
Implementation details:

* [docker/17989](https://github.com/moby/moby/pull/17989): initial
implementation
* [docker/18780](https://github.com/moby/moby/pull/18780): default blacklist
profile
* [docker/18979](https://github.com/moby/moby/pull/18979): default whitelist
profile

### rkt / appcontainers

The `rkt` runtime delegates to systemd for seccomp support; there is an open
issue to add support once `appc` supports it. The `appc` project has an open
Expand All @@ -133,23 +141,23 @@ Issues:
* [appc/529](https://github.com/appc/spec/issues/529)
* [rkt/1614](https://github.com/coreos/rkt/issues/1614)

#### HyperContainer
### HyperContainer

[HyperContainer](https://hypercontainer.io) does not support seccomp.

### Other platforms and seccomp-like capabilities

FreeBSD has a seccomp/capability-like facility called
[Capsicum](https://www.freebsd.org/cgi/man.cgi?query=capsicum&sektion=4).

#### lxd
### lxd

[`lxd`](http://www.ubuntu.com/cloud/lxd) constrains containers using a default profile.

Issues:

* [lxd/1084](https://github.com/lxc/lxd/issues/1084): add knobs for seccomp

### Other platforms and seccomp-like capabilities

FreeBSD has a seccomp/capability-like facility called
[Capsicum](https://www.freebsd.org/cgi/man.cgi?query=capsicum&sektion=4).

## Proposed Design

### Seccomp API Resource?
Expand All @@ -168,8 +176,6 @@ Instead of implementing a new API resource, we propose that pods be able to
reference seccomp profiles by name. Since this is an alpha feature, we will
use annotations instead of extending the API with new fields.

### API changes?

In the alpha version of this feature we will use annotations to store the
names of seccomp profiles. The keys will be:

Expand All @@ -191,7 +197,8 @@ profiles to be opaque to kubernetes for now.

The following format is scoped as follows:

1. `docker/default` - the default profile for the container runtime
1. `docker/default` - the default profile for the container runtime, can be
Copy link
Member

@liggitt liggitt Mar 22, 2018

Choose a reason for hiding this comment

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

this is the default for all runtimes? or just the docker runtime?

Copy link
Contributor

@smarterclayton smarterclayton Mar 23, 2018

Choose a reason for hiding this comment

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

Yeah, should be runtime/default or container/default or default.

Copy link
Member Author

@wangzhen127 wangzhen127 Mar 23, 2018

Choose a reason for hiding this comment

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

I agree that we should use a general term to cover all kinds of runtimes. The current immediate step is to enable docker/default for docker runtime, which covers a lot of our use cases. Having a general seccomp default will need spec, ect.

Copy link
Member

@tallclair tallclair Mar 26, 2018

Choose a reason for hiding this comment

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

Agree we should use runtime/default, which is consistent with AppArmor and basically means "this is runtime dependent". runtime/default should be the same as docker/default in the docker runtime.

overwritten by the following two.
2. `unconfined` - unconfined profile, ie, no seccomp sandboxing
3. `localhost/<profile-name>` - the profile installed to the node's local seccomp profile root

Expand Down