This patch fixes exec to use the original (start-time) process exec
configuration. Otherwise, we were creating a brand new spec process w/o
additional groups for instance.
Spotted while integrating CRI-O with cri-test...The test was failing
with:
```
• Failure [10.640 seconds]
[k8s.io] Security Context
/home/amurdaca/go/src/github.com/kubernetes-incubator/cri-tools/pkg/framework/framework.go:72
bucket
/home/amurdaca/go/src/github.com/kubernetes-incubator/cri-tools/pkg/validate/security_context.go:407
runtime should support SupplementalGroups [It]
/home/amurdaca/go/src/github.com/kubernetes-incubator/cri-tools/pkg/validate/security_context.go:272
Expected
<[]string | len:1, cap:1>: ["0"]
to contain element matching
<string>: 1234
```
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
We now can pass 37/55 tests with this PR. Remaining tests include may be fixed
with 1.8.
[Fail] [k8s.io] Security Context bucket [It] runtime should support RunAsUserName
[Fail] [k8s.io] Security Context NamespaceOption [It] runtime should support HostPID
[Fail] [k8s.io] PodSandbox runtime should support sysctls [It] should support unsafe sysctls
[Fail] [k8s.io] PodSandbox runtime should support basic operations on PodSandbox [It] runtime should support removing PodSandbox [Conformance]
[Fail] [k8s.io] Streaming runtime should support streaming interfaces [It] runtime should support portforward [Conformance]
[Fail] [k8s.io] Security Context SeccompProfilePath [It] runtime should not support a custom seccomp profile without using localhost/ as a prefix
[Fail] [k8s.io] Image Manager [It] listImage should get exactly 2 repoTags in the result image [Conformance]
[Fail] [k8s.io] PodSandbox runtime should support sysctls [It] should support safe sysctls
[Fail] [k8s.io] Security Context NoNewPrivs [It] should not allow privilege escalation when true
[Fail] [k8s.io] Security Context SeccompProfilePath [It] runtime should support an seccomp profile that blocks setting hostname with SYS_ADMIN
[Fail] [k8s.io] Container runtime should support mount propagation [It] mount with 'rslave' should support propagation from host to container
[Fail] [k8s.io] Container runtime should support mount propagation [It] mount with 'rshared' should support propagation from host to container and vice versa
[Fail] [k8s.io] Networking runtime should support networking [It] runtime should support port mapping with host port and container port [Conformance]
[Fail] [k8s.io] Security Context SeccompProfilePath [It] should support seccomp localhost/profile on the container
[Fail] [k8s.io] Container runtime should support log [It] runtime should support starting container with log [Conformance]
[Fail] [k8s.io] Security Context bucket [It] runtime should support RunAsUser
[Fail] [k8s.io] Security Context bucket [It] runtime should support SupplementalGroups
[Fail] [k8s.io] Security Context SeccompProfilePath docker/default [It] should support seccomp docker/default on the container
Signed-off-by: baude <bbaude@redhat.com>
When running cri-tests with cri-o, I found out that cri-o panicked
immediately with the following message. Fix it by accessing to the
labels map only if it's non-nil.
```
panic: assignment to entry in nil map
goroutine 57 [running]:
.../cri-o/server.(*Server).RunPodSandbox(0xc42048e000, 0x7efcad4cd400,
0xc42066ec90, 0xc4201703d0, 0x0, 0x0, 0x0)
.../cri-o/server/sandbox_run.go:225 +0xda5
.../cri-o/vendor/k8s.io/kubernetes/pkg/kubelet/apis/cri/v1alpha1/runtime
._RuntimeService_RunPodSandbox_Handler(0x21793e0, 0xc42048e000,
0x7efcad4cd400, 0xc42066ec90, 0xc4204fe780, 0x0, 0x0, 0x0, 0x0, 0x0)
.../cri-o/vendor/k8s.io/kubernetes/pkg/kubelet/apis/cri/v1alpha1/runtime/api.pb.go:3645 +0x279
.../cri-o/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc420
09e3c0, 0x33e79c0, 0xc4203d1950, 0xc42080a000, 0xc4202bb980, 0x33b1d58,
0xc42066ec60, 0x0, 0x0)
.../cri-o/vendor/google.golang.org/grpc/server.go:638 +0x99c
```
Signed-off-by: Dongsu Park <dongsu@kinvolk.io>
server: fix selinux labels for pod and containers
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
sandbox: set selinux labels from request, not defaults
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
container_create: use sandbox's selinux if container's nil
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
sandbox: correctly init selinux labels
First, we weren't correctly initializing selinux labels. If any of
(level, user, role, type) was missing from kube selinux options, we
were erroring out. This is wrong as kube sends just `level=s0`
sometimes and docker itself allows `--security-opt label=level:s0`.
This patch directly initializes selinux labels, correctly, and adds a
test to verify it.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
test: testdata: use container_runtime_t selinux type
RHEL SELinux policy doesn't have `container_t` type but we're using it
in our fixtures. That means Fedora integration tests pass because
`container_t` is in Fedora's container policy but RHEL is broken.
Fix it by using `container_runtime_t` which is aliased in Fedora policy
to `container_t`.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Also, we distinguish between container and a pod infra
container in the exit monitor as pod infra containers
aren't stored in the main container index.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
We calculate these values at container creation time and store
them in the container object as they are requested during container
status. This avoids re-calculation and speeds up container status.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Need to mv to latest released and supported version of logrus
switch github.com/Sirupsen/logrus github.com/sirupsen/logrus
Also vendor in latest containers/storage and containers/image
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
The storage library uses github.com/pkg/errors to wrap errors that it
returns from many of its functions, so when passing them to
os.IsNotExist() or comparing them to specific errors defined in the
storage library, unwrap them using errors.Cause().
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
If sandbox is in the same package as server, there will be a circular dependency when
kpod create is implemented
Signed-off-by: Ryan Cole <rcyoalne@gmail.com>
Move non-kubernetes-dependent portions of server struct to libkpod.
So far, only the struct fields have been moved and not their dependent
functions
Signed-off-by: Ryan Cole <rcyoalne@gmail.com>
The syscall package is locked down and the comment in [1] advises to
switch code to use the corresponding package from golang.org/x/sys. Do
so and replace usage of package syscall where possible (leave
syscall.SysProcAttr and syscall.Stat_t).
[1] https://github.com/golang/go/blob/master/src/syscall/syscall.go#L21-L24
This will also allow to get updates and fixes just by re-vendoring
golang.org/x/sys/unix instead of having to update to a new go version.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
This matches the current kube behavior. This will probably
be provided over the CRI at which point we won't have to
define a constant in cri-o code.
Signed-off-by: Mrunal Patel <mpatel@redhat.com>
If we get a kubelet annotation about the sandbox trust level, we use it
to toggle our sandbox trust flag.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Container runtimes provide different levels of isolation, from kernel
namespaces to hardware virtualization. When starting a specific
container, one may want to decide which level of isolation to use
depending on how much we trust the container workload. Fully verified
and signed containers may not need the hardware isolation layer but e.g.
CI jobs pulling packages from many untrusted sources should probably not
run only on a kernel namespace isolation layer.
Here we allow CRI-O users to define a container runtime for trusted
containers and another one for untrusted containers, and also to define
a general, default trust level. This anticipates future kubelet
implementations that would be able to tag containers as trusted or
untrusted. When missing a kubelet hint, containers are trusted by
default.
A container becomes untrusted if we get a hint in that direction from
kubelet or if the default trust level is set to "untrusted" and the
container is not privileged. In both cases CRI-O will try to use the
untrusted container runtime. For any other cases, it will switch to the
trusted one.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
