Bug 1392749

Summary: Seccomp profile default directory is missing
Product: OpenShift Container Platform Reporter: Weihua Meng <wmeng>
Component: NodeAssignee: Seth Jennings <sjenning>
Status: CLOSED ERRATA QA Contact: Weihua Meng <wmeng>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.4.0CC: agoldste, aos-bugs, dma, jokerman, mmccomas, tdawson
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
This bug fixes and issue when using the seccomp profile annotation in a pod definition. The default directory for the location of seccomp profile json files on the node is not set properly. With this fix, the default seccomp profile directory is appropriately set to /var/lib/kubelet/seccomp.
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-18 12:50:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Weihua Meng 2016-11-08 06:54:39 UTC
Description of problem:
Seccomp profile default directory is missing

Version-Release number of selected component (if applicable):
openshift v3.4.0.23+24b1a58
kubernetes v1.4.0+776c994
etcd 3.1.0-rc.0

How reproducible:
Always

Steps to Reproduce:
1. on master, configure the restricted SCC

# oc edit scc restricted

seccompProfiles:
- '*'

2. login OpenShift with normal user on other host

# oc login <.....>

3. oc create -f pod-sec-pod-prof1.yaml
pod "pod-seccomp-prof1-pod" created

# cat  pod-sec-pod-prof1.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    name: pod-seccomp
  name: pod-seccomp-prof1-pod
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: localhost/profile1.json
spec:
  containers:
    - image: "docker.io/deshuai/hello-pod:latest"
      imagePullPolicy: IfNotPresent
      name: hello-pod
      ports:
        - containerPort: 8080
          protocol: TCP
      resources: {}
      securityContext:
        capabilities: {}
        privileged: false
      terminationMessagePath: /dev/termination-log
      volumeMounts:
        - mountPath: /tmp
          name: tmp
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  serviceAccount: ""
  volumes:
    - emptyDir: {}
      name: tmp
status: {}

4.# oc describe pod pod-seccomp-prof1-pod


Actual results:
<-----snip----->
  33m		7s		149	{kubelet host-8-174-246.host.centralci.eng.rdu2.redhat.com}			Warning		FailedSync	Error syncing pod, skipping: failed to "StartContainer" for "POD" with RunContainerError: "runContainer: cannot load seccomp profile \"profile1.json\": open profile1.json: no such file or directory"

Expected results:
information about the location to get the profile
something like this
FailedSync    Error syncing pod, skipping: failed to "StartContainer" for "POD" with RunContainerError: "runContainer: cannot load seccomp profile \"profilenotfound.json\": open  /var/lib/kubelet/seccomp/profile1.json: no such file or directory"

Additional info:

Comment 1 DeShuai Ma 2016-11-08 08:37:25 UTC
In upstream fixed by https://github.com/kubernetes/kubernetes/pull/36375

Comment 2 Seth Jennings 2016-11-08 17:34:58 UTC
Origin cherry-pick PR:
https://github.com/openshift/origin/pull/11839

Comment 3 Troy Dawson 2016-11-11 19:34:27 UTC
This has been merged into ose and is in OSE v3.4.0.25 or newer.

Comment 5 Weihua Meng 2016-11-12 12:23:29 UTC
Verified.
openshift v3.4.0.25+1f36858
kubernetes v1.4.0+776c994
etcd 3.1.0-rc.0

Message
Error syncing pod, skipping: failed to "StartContainer" for "POD" with RunContainerError: "runContainer: cannot load seccomp profile \"profile1.json\": open /var/lib/kubelet/seccomp/profile1.json: no such file or directory"

Comment 7 errata-xmlrpc 2017-01-18 12:50:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:0066