cert-manager-acmesolver v0.14.0 runs as root which leads to failure in restricted namespaces

Created on 21 Mar 2020  路  3Comments  路  Source: jetstack/cert-manager

Describe the bug:
cert-manager-acmesolver in version 0.14 runs as user root and when it tries to run cm-acme-http-solver pod in restricted, production namespaces where running container as root is forbidden it fails:

cm-acme-http-solver-lqlxj                               0/1     CreateContainerConfigError   0          36m
  containerStatuses:
  - image: quay.io/jetstack/cert-manager-acmesolver:v0.14.0
    imageID: ""
    lastState: {}
    name: acmesolver
    ready: false
    restartCount: 0
    state:
      waiting:
        message: container has runAsNonRoot and image will run as root
        reason: CreateContainerConfigError



md5-4ccc51c0c0a91f4b3d43595a69631f3f



apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default'
    apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
    seccomp.security.alpha.kubernetes.io/defaultProfileName:  'runtime/default'
    apparmor.security.beta.kubernetes.io/defaultProfileName:  'runtime/default'
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
  - ALL
  volumes:
  - 'configMap'
  - 'emptyDir'
  - 'projected'
  - 'secret'
  - 'downwardAPI'
  - 'persistentVolumeClaim'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
    - min: 1
      max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
    - min: 1
      max: 65535
  readOnlyRootFilesystem: false
  1. Try to get ACME certificate with http01 solver for workload in this namespace.

Anything else we need to know?:

Environment details::

  • Kubernetes version (e.g. v1.10.2): v1.15.9-gke.9
  • Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): GKE
  • cert-manager version (e.g. v0.4.0): v0.14.0
  • Install method (e.g. helm or static manifests): static manifests

/kind bug

kinbug

Most helpful comment

@meyskens I see the same behaviour in 0.14.1:

docker inspect quay.io/jetstack/cert-manager-controller:v0.14.1
[...]
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "",

in comparison to 0.13:

docker inspect quay.io/jetstack/cert-manager-controller:v0.13.0
[...]
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "1000",

Is it really fixed in 0.14.1?

All 3 comments

This is a known issue in 0.14, fixed in https://github.com/jetstack/cert-manager/pull/2720
We will soon release 0.14.1 with this patch included! Sorry for this.

@meyskens I see the same behaviour in 0.14.1:

docker inspect quay.io/jetstack/cert-manager-controller:v0.14.1
[...]
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "",

in comparison to 0.13:

docker inspect quay.io/jetstack/cert-manager-controller:v0.13.0
[...]
        "Config": {
            "Hostname": "",
            "Domainname": "",
            "User": "1000",

Is it really fixed in 0.14.1?

Im facing the same isuse with v0.14.1 release.

image: quay.io/jetstack/cert-manager-acmesolver:v0.14.1
    imagePullPolicy: Always
    name: acmesolver
    ports:
    - containerPort: 8089
      name: http
      protocol: TCP
    resources:
      limits:
        cpu: 100m
        memory: 64Mi
      requests:
        cpu: 10m
        memory: 64Mi
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - NET_RAW
      runAsNonRoot: true

error:

  containerStatuses:
  - image: quay.io/jetstack/cert-manager-acmesolver:v0.14.1
    imageID: ""
    lastState: {}
    name: acmesolver
    ready: false
    restartCount: 0
    started: false
    state:
      waiting:
        message: container has runAsNonRoot and image will run as root
        reason: CreateContainerConfigError
Was this page helpful?
0 / 5 - 0 ratings