Skip to content
This repository has been archived by the owner on Dec 19, 2019. It is now read-only.

Test of seccomp profile "docker/default" fails #143

Closed
dongsupark opened this issue Sep 29, 2017 · 1 comment · Fixed by #146
Closed

Test of seccomp profile "docker/default" fails #143

dongsupark opened this issue Sep 29, 2017 · 1 comment · Fixed by #146
Milestone
v0.1.0

Comments

@dongsupark
Copy link
Contributor

dongsupark commented Sep 29, 2017 •
edited
Loading

There are many seccomp tests that fail. One of the simple examples is the test "should support seccomp docker/default on the container".

• Failure [4.215 seconds]
[k8s.io] Security Context
/home/dpark/go/src/github.com/kubernetes-incubator/cri-tools/pkg/framework/framework.go:72
  SeccompProfilePath
  /home/dpark/go/src/github.com/kubernetes-incubator/cri-tools/pkg/validate/security_context.go:410
    docker/default
    /home/dpark/go/src/github.com/kubernetes-incubator/cri-tools/pkg/validate/security_context.go:559
      should support seccomp docker/default on the container [It]
      /home/dpark/go/src/github.com/kubernetes-incubator/cri-tools/pkg/validate/security_context.go:560

      Expected
          <string>: Seccomp:	0
          
      to contain substring
          <string>: 2

      /home/dpark/go/src/github.com/kubernetes-incubator/cri-tools/pkg/validate/security_context.go:906

That means basically that /proc/self/status shows Seccomp: 0 (not in seccomp mode). As rkt already supports the default seccomp profile docker/default, I'm not sure I understand.

On the other hand, not all seccomp tests fail. For example, the test runtime should support setting hostname with docker/default seccomp profile and SYS_ADMIN succeeds. Strange.
@iaguis
Copy link
Contributor

iaguis commented Sep 29, 2017

I think the problem is related to how we implement seccomp in the rktlet.

In 8088ab5 I implemented the forwarding of seccomp options, but I only did it through annotations since that's what's implemented in v1.7.x. However, later (in v1.8.0) they moved it to a field in SecurityContext, which is what should support seccomp docker/default on the container is using. I'm not sure why the other seccomp tests pass.

Even though the cri-tools readme says "We are currently working toward an alpha version of CRI validation tests to be used in conjunction with Kubernetes 1.7.", it seems cri-tools v0.2 bumps the CRI interface to v1.8.

@dongsupark dongsupark mentioned this issue Oct 5, 2017
Merged
@iaguis iaguis added this to the v0.1.0 milestone Nov 15, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
v0.1.0
Development

Successfully merging a pull request may close this issue.

rktlet: use seccompProfilePath for k8s 1.8 kinvolk-archives/rktlet
2 participants
@iaguis @dongsupark