Docker : sécurité des images avec l’outil img | Padok Security

# Based on: https://github.com/genuinetools/img/blob/master/Dockerfile

# ----- img ------
FROM golang:1.13-alpine AS img

RUN apk add --no-cache \
	bash \
	build-base \
	gcc \
	git \
	libseccomp-dev \
	linux-headers \
	make

WORKDIR /img
RUN go get github.com/go-bindata/go-bindata/go-bindata
RUN git clone https://github.com/genuinetools/img \
  && cd img \
  && git checkout 16d3b6cad7e72f4cd9c8dad0e159902eeee00898 \
  && make static \
  && mv img /usr/bin/img

# ----- idmap ------
FROM alpine:3.11 AS idmap
RUN apk add --no-cache autoconf automake build-base byacc gettext gettext-dev gcc git libcap-dev libtool libxslt
RUN git clone https://github.com/shadow-maint/shadow.git /shadow
WORKDIR /shadow
RUN git checkout 59c2dabb264ef7b3137f5edb52c0b31d5af0cf76
RUN ./autogen.sh --disable-nls --disable-man --without-audit --without-selinux --without-acl --without-attr --without-tcb --without-nscd \
  && make \
  && cp src/newuidmap src/newgidmap /usr/bin

# ----- img and idmap -----
FROM alpine:3.11 AS base
RUN apk add --no-cache git pigz
COPY --from=img /usr/bin/img /usr/bin/img
COPY --from=idmap /usr/bin/newuidmap /usr/bin/newuidmap
COPY --from=idmap /usr/bin/newgidmap /usr/bin/newgidmap

RUN chmod u+s /usr/bin/newuidmap /usr/bin/newgidmap \
  && adduser -D -u 1000 user \
  && mkdir -p /run/user/1000 \
  && chown -R user /run/user/1000 /home/user \
  && echo user:100000:65536 | tee /etc/subuid | tee /etc/subgid

# ----- add fuse-overlayfs and tools -----
FROM base AS final
WORKDIR /build
RUN apk add git make gcc libc-dev musl-dev glib-static gettext eudev-dev \
	linux-headers automake autoconf cmake meson ninja clang go-md2man

RUN git clone https://github.com/libfuse/libfuse && \
    cd libfuse && \
    mkdir build && \
    cd build && \
    LDFLAGS="-lpthread -s -w -static" meson --prefix /usr -D default_library=static .. && \
    ninja && \
    ninja install

RUN git clone https://github.com/containers/fuse-overlayfs \
  && cd fuse-overlayfs \
  && git checkout v1.8.2
RUN cd fuse-overlayfs && \
    ./autogen.sh && \
    LIBS="-ldl" LDFLAGS="-s -w -static" ./configure --prefix /usr && \
    make clean && \
    make && \
    make install

RUN apk add --no-cache \
    bash \
    jq \
    py3-pip \
  && pip3 install --no-cache-dir awscli \
  && rm -rf /var/cache/apk/*

# ----- rootless -----
FROM final AS release
USER user
ENV USER user
ENV HOME /home/user
ENV XDG_RUNTIME_DIR=/run/user/1000
WORKDIR /home/user

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: generic-device-plugin
  namespace: gitlab
  labels:
    app.kubernetes.io/name: generic-device-plugin
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: generic-device-plugin
  template:
    metadata:
      labels:
        app.kubernetes.io/name: generic-device-plugin
    spec:
      priorityClassName: system-node-critical
      nodeSelector:
        kube/nodetype: gitlab
      containers:
      - image: squat/generic-device-plugin
        # count specifies that 15 pod are allowed to use the device simulteously
        args:
        - --device
        - '{"name": "fuse", "groups": [{"count": 15, "paths": [{"path": "/dev/fuse"}]}]}'
        name: generic-device-plugin
        ports:
        - containerPort: 8080
          name: http
        securityContext:
          privileged: true
        volumeMounts:
        - name: device-plugin
          mountPath: /var/lib/kubelet/device-plugins
        - name: dev
          mountPath: /dev
      volumes:
      - name: device-plugin
        hostPath:
          path: /var/lib/kubelet/device-plugins
      - name: dev
        hostPath:
          path: /dev
  updateStrategy:
    type: RollingUpdate

Mutation policy Kyverno

Les deux étapes suivantes sont un petit trick pour ajouter la limits pour le device fuse aux pods du Runner Gitlab dans notre cluster Kubernetes. En effet, le template helm générique des Runners Gitlab ne permet pas de modifier les limitss des pods. Nous allons donc créer à une policy Kyverno pour modifier à la volée nos pods et rajouter la limits squat.ai/fuse: 1 pour le device fuse à tous les pods posédant le label mount-fuse: "true"

apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: add-fuse-device
  namespace: gitlab
spec:
  rules:
  - name: add-fuse-device
    match:
      any:
      - resources:
          kinds:
          - Pod
          selector:
            matchLabels:
              mount-fuse: "true"
    mutate:
      patchesJson6902: |-
        - op: add
          path: "/spec/containers/0/resources/limits"
          value: {"squat.ai/fuse":"1"}

Configuration des Runners Gitlab

Il suffit ensuite de modifier la configuration des Runners Gitlab pour ajout le label mount-fuse: "true" aux pods dans Kubernetes.

runners:
    config: |
      [[runners]]
        [runners.kubernetes]
					[runners.kubernetes.pod_labels]
						mount-fuse = "true"

Utilisation

Pour builder nos images de manière sécurisée, il suffit maintenant de remplacer docker par img dans notre CI, à quelques exceptions près :

• Le paramètre --network n’existe pas pour img, mais est actif par défaut
• Pour les build-args il faut obligatoirement préciser le nom et la valeur de la variable :
  • --build-arg "MYVAR=$MYVAR"
• img push ne pousse pas plusieurs tags d’une même image en même temps (contrairement à docker push), il faut un img push pour chaque tag.
• docker rmi devient img rm

Exemple d’un job de CI

.release-java:
  stage: release
  image: my-repo/img-aws:1.0.0
  before_script:
    - cp -r configuration $WORKDIR
    - cd $WORKDIR
    - aws ecr get-login-password --region eu-west-3 | img login --username AWS --password-stdin ${DOCKER_URL}
    - if [[ ! -z $CI_COMMIT_TAG ]]; then export DOCKER_TAG=$(echo
      $CI_COMMIT_REF_NAME | tr @ _); fi;
  script:
    - img build
      --cache-from ${DOCKER_URL}/${DOCKER_REPO}/${DOCKER_IMAGE}:${TARGET_ENV}-latest
      -t ${DOCKER_URL}/${DOCKER_REPO}/${DOCKER_IMAGE}:${DOCKER_TAG}
      -t ${DOCKER_URL}/${DOCKER_REPO}/${DOCKER_IMAGE}:${TARGET_ENV}-latest
      -f docker/ci.Dockerfile
      --build-arg "MY_VAR=$MYVAR"
    - img push ${DOCKER_URL}/${DOCKER_REPO}/${DOCKER_IMAGE}:${DOCKER_TAG}
    - img push ${DOCKER_URL}/${DOCKER_REPO}/${DOCKER_IMAGE}:${TARGET_ENV}-latest
    - img rm ${DOCKER_URL}/${DOCKER_REPO}/${DOCKER_IMAGE}:${DOCKER_TAG}
    - img rm ${DOCKER_URL}/${DOCKER_REPO}/${DOCKER_IMAGE}:${TARGET_ENV}-latest
  variables:
    DOCKER_TAG: ${CI_COMMIT_SHA}

Conclusion

Nous venons de voir pourquoi la méthode docker-in-docker n’est pas sécurisée pour le build d’image dans Kubernetes. Nous avons ensuite exploré une solution basée sur img mais qui nécessite pas mal d’actions sur Kubernetes pour obtenir de bonnes performances.

Une autre solution possible sécurisée que nous n’avons pas détaillé ici est d’utiliser Kaniko. Nous n’avons pas choisi cette solution car, à notre sens, elle est moins souple que img. En effet, l’image kaniko ne prend pas en charge l’ajout d’autres étapes que le build d’image.

Pourtant, il s'avère souvent intéressant d’effectuer des actions après le build comme un scan de l’image par exemple.