Anchore – Análisis de vulnerabilidades de docker

0
3099
Ciclo de Anchore

Índice de contenidos

1.​ Introducción

Este tutorial explica la herramienta para análisis de vulnerabilidades de imagen de docker Anchore. Aprenderemos cómo configurarlo para descargar una imagen de un repositorio de docker, ya sea público o privado (añadiendo las credenciales del repositorio a anchore). También cómo analizar imágenes de docker en local, obtener informes con toda la información que Anchore proporciona y ejecutar una evaluación de la imagen contra distintas políticas para comprobar si la imagen supera el umbral de calidad de la política activa en Anchore.

Además de cómo configurar Anchore como una fase de integración continua (usaremos Gitlab CI en este tutorial) para automatizar el proceso de análisis de imágenes cada vez que haya una subida al repositorio.

Vamos a ver dos variantes de uso de Anchore en integración continua: 

  • Subir la imagen a un repositorio de docker, analizarla desde ahí y utilizar Anchore como medida preventiva para no desplegar esa imagen en kubernetes 
  • Solo subir la imagen de docker al repositorio si esta supera el umbral de la política activa.

Puedes encontrar el código de este tutorial en este repositorio.

​2.​ ¿Qué es Anchore?

Anchore es un herramienta de código abierto (también tiene version empresarial, pero no la vamos a cubrir en este tutorial) que inspecciona, analiza y certifica las imágenes de Docker. Este análisis lo hace contra una base de datos propia (Postgres) formada por la recopilación de información de vulnerabilidades y problemas de seguridad (CVE) de distribuciones de sistemas operativos y también recopila esa misma información de los registros de paquetes populares como Node.JS, NPM, Ruby.

Anchore puede descargar cualquier imagen de un registro compatible con docker V2 y el resultado del análisis genera un reporte con los detalles de la imagen, un listado de artefactos (npm, gem, python y java), un listado de paquetes del sistema operativo, el listado de ficheros de la imagen y un listado de vulnerabilidades (a elegir entre todas, solo del sistema operativo o solo las que no tengan que ver con el sistema operativo).

 

3.​ Cómo funciona Anchore

Anchore analiza cada imagen basándose en datos y la aplicación de políticas. Anchore sigue las siguientes fases en cada análisis:

  1. Obtiene y extrae el contenido de la imagen, sin ejecutarlo.
  2. Analiza el contenido, extrayendo y clasificando la mayor cantidad posible de metadatos.
  3. Guarda el resultado del análisis anterior en la base de datos.
  4. Evalúa las políticas contra el resultado del análisis, incluidas las coincidencias de vulnerabilidades en los artefactos descubiertos en la imagen.
  5. Actualiza los datos utilizados para la evaluación de políticas y vulnerabilidades y si hay algún cambio en estos datos, actualiza los resultados del análisis de imágenes aplicando estos nuevos datos.
  6. Muestra al usuario los resultados

​3.1.​ Origen base de datos de vulnerabilidades

La base de datos de Anchore solo cuenta por defecto con información de vulnerabilidades, pero se puede indicar a Anchore para que también incluya información de paquetes como npm y gem, además de bases de datos como nvd u otras externas.

En esta tabla se pueden ver los distintos origen de la fuente de datos, el tipo de datos y el controlador al que pertenecen:

Driver Feed Type External Data Source
alpine vulnerabilities https://github.com/alpinelinux/alpine-secdb/archive/master.tar.gz
centos vulnerabilities https://www.redhat.com/security/data/oval/com.redhat.rhsa-all.xml.bz2
debian vulnerabilities https://security-tracker.debian.org/tracker/data/jsonhttps://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/DSA/list
oracle vulnerabilities https://linux.oracle.com/security/oval/com.oracle.elsa-all.xml.bz2
ubuntu vulnerabilities https://launchpad.net/ubuntu-cve-tracker
gem packages https://s3-us-west-2.amazonaws.com/rubygems-dumps
npm packages https://replicate.npmjs.com
nvd nvd https://nvd.nist.gov/vuln/data-feeds
snyk snyk https://data.anchore-enterprise.com

 

4.​ Cómo usar Anchore

Anchore está disponible como una imagen de Docker. Esta imagen se puede ejecutar de forma independiente con docker-compose en una máquina local, con plataformas de orquestación como Kubernetes o como parte de integración continua en Gitlab CI, Jenkins, Travis CI, etc.

Para usarlo por primera vez y probar la herramienta recomiendo ejecutarlo en local con docker-compose al ser la forma más rápida para poder ejecutar todos los comandos y ver la funcionalidad.

Después de haberlo probado con docker-compose, la mayor utilidad de Anchore es usarlo como parte de una fase de integración continua que se ejecute con cada cambio de una imagen de docker para comprobar que no hay nuevas vulnerabilidades o se han corregido las que ya había.

4.1.​ Anchore en local con docker-compose

Para poder usar Anchore hay que descargar (con el comando de abajo) la última imagen del contenedor de Anchore Engine que contiene el docker-compose.yaml y demás ficheros de configuración.

docker pull docker.io/anchore/anchore-engine:latest

Vamos a copiar el fichero docker-compose.yaml que hay dentro de anchore-engine a la carpeta ~/anchore/

docker create --name anchore docker.io/anchore/anchore-engine:latest
docker cp anchore:/docker-compose.yaml ~/anchore/docker-compose.yaml
docker rm anchore

Ahora entramos a la carpeta y descargamos los contenedores descritos dentro del fichero docker-compose.yaml que hay en la carpeta.

cd ~/anchore
docker-compose pull

Por defecto todos los servicios, incluida la base de datos no son persistentes y al reiniciar o apagar se perderán, pero se puede hacer persistente con tan solo poner a true la propiedad external dentro de anchore-db-volume y haber previamente creado un volumen de docker ejecutando

docker volume create anchore-db-volume

Ejecutamos el docker-compose:

docker-compose up -d

Una vez levantado Anchore podemos comprobar que funciona con docker-compose ejecutando

docker-compose exec engine-api anchore-cli system status

Tenemos todo listo para empezar a ejecutar el flujo básico de análisis de una imagen, solo hay que ejecutar estos comandos de abajo en orden sustituyendo el entrecomillado imagen por el nombre:tag o el digest de la imagen a analizar. Para probarlo inicialmente podemos analizar cualquier imagen de docker hub como por ejemplo “adoptopenjdk/openjdk11:latest” en lugar de “imagen”.

docker-compose exec engine-api anchore-cli system wait
docker-compose exec engine-api anchore-cli image add “imagen”
docker-compose exec engine-api anchore-cli image wait “imagen”
docker-compose exec engine-api anchore-cli image vuln “imagen” all
docker-compose exec engine-api anchore-cli evaluate check “imagen” --detail

Es recomendable usar el digest de la imagen en vez de solo el nombre para evitar problemas de ambigüedad en caso de que la imagen cambie pero el nombre y tag. En este caso queremos analizar solo la última versión de la imagen, no queremos una imagen anterior especifica, así que podemos hacerlo solo poniendo el nombre.

Cuando se aplica el bundle de políticas por defecto (más adelante explicado) de Anchore el estado de éxito puede darse si:

  • La imagen evaluada está totalmente limpia de problemas, 
  • Solo hay warnings 
  • La imagen evaluada está en la lista blanca (no se evalúa). 

El estado fallido se da si: 

  • La imagen evaluada tiene al menos una vulnerabilidad que en el bundle de políticas está marcada como Stop
  • La imagen estaba en la lista negra (falla sin analizarla)

4.2.​ Anchore en integración continua (Gitlab CI)

La mayor virtud de Anchore es la facilidad de usarlo en un ciclo de integración continua para securizar los contenedores docker desplegados. De esta forma añadimos una capa de seguridad a la entrega continua.

Para mostrar un ejemplo de implementación de Anchore, he elegido Gitlab CI por ser gratuito (2000 horas al mes de ejecución de integración continua) y fácil de configurar para que cualquier commit que se suba al repositorio ejecute la integración continua con la fase de Anchore.

Anchore también se puede integrar con Jenkins, Travis CI o cualquier otro sistema de integración continua, contando con utilidades y ejemplos para facilitar la integración. Además de usarlo como imagen de docker, Anchore también se puede desplegar en Kubernetes como un pod que estará en el cluster de kubernetes siempre disponible. De tal forma que se pueda usar Anchore para otros propósitos solo usando la url del despliegue en vez de tener Anchore ejecutándose como una imagen de docker solo activa en el momento de la integración continua.

Según el objetivo que queramos conseguir podemos utilizar Anchore de dos formas distintas. La diferencia entre ellas es que para el primer método necesitamos que la imagen de docker esté subida a un repositorio para que Anchore la pueda descargar y analizar y para el segundo solo necesitamos dar a Anchore el dockerfile con el que construir la imagen de docker y esa imagen construida en local.

 

4.2.1.​ Analizar imágenes de docker una vez han sido subidas a un repositorio

Una vez almacenada la imagen de docker podemos analizar las vulnerabilidades que tiene esa imagen y decidir si es o no apta para desplegarla al entorno que elijamos. Después de esta fase de análisis podemos poner la fase de despliegue de esa imagen, asi solo si pasa el análisis se podrá ejecutar la fase de despliegue

repo_anchore_scan:
 image: anchore/engine-cli:latest
 variables:
   GIT_STRATEGY: none
   ANCHORE_CLI_URL: "http://anchore-engine:8228/v1"
   ANCHORE_SCAN_IMAGE: jesus12345/$IMAGE_NAME
   ANCHORE_TIMEOUT: 300
   ANCHORE_FAIL_ON_POLICY: "true"

 services:
   - name: docker.io/anchore/inline-scan:latest
     alias: anchore-engine
     command: ["start"]

 script:
   - anchore-cli --debug system wait
   - echo "Adding image to Anchore engine"
   - anchore-cli image add ${ANCHORE_SCAN_IMAGE}
   - echo "Waiting for analysis to complete"
   - anchore-cli image wait ${ANCHORE_SCAN_IMAGE} --timeout ${ANCHORE_TIMEOUT}
   - echo "Analysis complete"
   - anchore-cli --json image content ${ANCHORE_SCAN_IMAGE} os > image-packages.json
   - anchore-cli --json image content ${ANCHORE_SCAN_IMAGE} npm > image-npm.json
   - anchore-cli --json image content ${ANCHORE_SCAN_IMAGE} gem > image-gem.json
   - anchore-cli --json image content ${ANCHORE_SCAN_IMAGE} python > image-python.json
   - anchore-cli --json image content ${ANCHORE_SCAN_IMAGE} java > image-java.json
   - anchore-cli --json image vuln ${ANCHORE_SCAN_IMAGE} all > image-vulnerabilities.json
   - anchore-cli --json image get ${ANCHORE_SCAN_IMAGE} > image-details.json
   - anchore-cli --json evaluate check ${ANCHORE_SCAN_IMAGE} --detail > image-policy.json || true
   - echo "Reporting completed"
   - if [ "${ANCHORE_FAIL_ON_POLICY}" == "true" ] ; then anchore-cli evaluate check ${ANCHORE_SCAN_IMAGE} --detail; fi
 
artifacts:
   name: anchore_scan-$CI_PROJECT_NAME
   paths:
     - image-policy.json
     - image-details.json
     - image-vulnerabilities.json
     - image-java.json
     - image-python.json
     - image-gem.json
     - image-npm.json
     - image-packages.json

 retry:
   max: 2
   when:
     - stuck_or_timeout_failure
     - runner_system_failure

Para poder ejecutar esta fase se necesitan las imágenes de Engine cli y Anchore engine. Engine cli contiene los comandos de Anchore. Inline scan contiene Anchore engine, que lo inyectamos como servicio para poder ejecutar los análisis.

Explicación de la fase:

  • Esperamos a que el engine de Anchore se inicie para evitar que la fase falle por ejecutar un comando sin tenerlo iniciado
  • Añadimos la imagen al engine de Anchore
  • Esperamos a que Anchore la analice
  • Ejecutamos todos los comandos que reportan información en los distintos ficheros
  • Ejecutamos la evaluación de políticas si hemos puesto la variable del if a True

Resultado de la fase:

Image Digest: 
sha256:7b022e8c46d0b41e60f46d4b6668345818c64c820498dbccbe99bf7e8c1a325a
Full Tag: docker.io/jesus12345/helm-docker-aws-cli-iam-authenticator:latest
Image ID: e6d6854c0ef83a78bcdeda807e9726bb439aa06ed82345825b62517c75dcf703
Status: pass
Last Eval: 2019-06-05T09:23:59Z
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
Final Action: warn
Final Action Reason: policy_evaluation

Gate              Trigger Detail                                                                                     Status       
dockerfile        instruction Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check     warn

La evaluación muestra información general de la imagen junto con el resultado, exitoso en este caso al tener el status pass, esto implica que la imagen ha superado la evaluación contra la política por defecto (al no haber configurado una política distinta aun) de Anchore.

Además del status, también se muestra que hay cosas a mejorar, al tener un warn en el final action, indicando que el warning lo lanzó la política evaluada y abajo muestra detalladamente dónde está el problema para que se pueda solucionar de cara a la siguiente vez.

 

4.2.2.​ Analizar la imagen de docker y dockerfile antes de subirlo a un repositorio

Podemos utilizar Anchore para evitar almacenar una imagen de docker que no cumple con las políticas que hayamos establecido.

En vez de mostrar solo un ejemplo de ejecución, voy a mostrar dos fases que analizan la imagen en local. La diferencia radica en que en la primera fase se aplica una política donde solo fallará el análisis si se descubre alguna vulnerabilidad crítica y en la segunda fase solo fallará si se descubren vulnerabilidades altas o críticas sin fix en el momento del análisis.
Esta comparativa es muy útil para mostrar la importancia de la política que se usa para analizar la imagen pues el resultado varía enormemente partiendo de la misma imagen.

variables:
  IMAGE_NAME: "helm-docker-aws-cli-iam-authenticator"
only-critical_inline_anchore_scan:
 image: docker:stable
 script:
   - apk update && apk --no-cache add curl bash
   - docker build -t example-image:latest -f $IMAGE_NAME/Dockerfile .
   - curl -s https://ci-tools.anchore.io/inline_scan-v0.3.3 | bash -s -- -f -d $IMAGE_NAME/Dockerfile -b anchore-policies/policy_bundle_only_critical.json example-image:latest
stop-high_inline_anchore_scan:
 image: docker:stable
 script:
   - apk update && apk --no-cache add curl bash
   - docker build -t example-image:latest -f $IMAGE_NAME/Dockerfile .
   - curl -s https://ci-tools.anchore.io/inline_scan-v0.3.3 | bash -s -- -f -d $IMAGE_NAME/Dockerfile -b anchore-policies/policy_bundle_stop_high_no_fix.json example-image:latest

Explicación de las fases:

  • Al partir de la imagen de docker hay que instalar curl y bash para que funcionen los comandos de ejecución del script.
  • Construimos la imagen de docker.
  • Ejecutamos el script de Anchore pasando el dockerfile, una política propia (esto es opcional y es la diferencia entre las fases, tambien se podria eliminar el flag y dejar que se use la politica por defecto) y el nombre de la imagen construida en el paso anterior.

Resultado de la fase (only-critical):

Image Digest: 
sha256:1d056e0a40284a38ee840c416143c1a33b49f2d7eea6bf7b2fecb23e733c1deb
Full Tag: anchore-engine:5000/example-image:latest
Image ID: d0349b1762b0b913eb831c5cd7300f95b664404f2c84bfb7f7f20ddcd933d816
Status: pass
Last Eval: 2019-06-05T09:36:46Z
Policy ID: only_critical
Final Action: go
Final Action Reason: policy_evaluation

Image Digest: sha256:1d056e0a40284a38ee840c416143c1a33b49f2d7eea6bf7b2fecb23e733c1deb
Full Tag: anchore-engine:5000/example-image:latest
Status: pass
Last Eval: 2019-06-05T09:36:47Z
Policy ID: only_critical

Este resultado tiene la peculiaridad de que se ha aplicado una política muy poco restrictiva, solo mostrando errores cuando la imagen tiene una vulnerabilidad crítica e ignorando el resto de vulnerabilidades en el resultado, debido a esto el resultado ha sido exitoso, dando un status pass y además no hay ningún problema detectado pues la acción es go.

 

Resultado de la fase (stop-high):

Image Digest: 
sha256:a2ca6b81deba65acb84362f105f829c9b015227271cffa82ecbd29c19bf3e917
Full Tag: anchore-engine:5000/example-image:latest
Image ID: c31f418e86b3e7e357e0e8a366799414e88a9ef9db165e3f0a145ff735ae8b24
Status: fail
Last Eval: 2019-06-05T09:49:51Z
Policy ID: stop_high_and_critical_with_fix
Final Action: stop
Final Action Reason: policy_evaluation

Gate                   Trigger Detail                                                                                                                                                                            Status       
dockerfile             instruction Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check                                                                                                        
vulnerabilities        package MEDIUM Vulnerability found in non-os package type (python) - /usr/lib/python2.7/dist-packages/pycrypto (CVE-2018-6594 - https://nvd.nist.gov/vuln/detail/CVE-2018-6594)            warn         
vulnerabilities        package MEDIUM Vulnerability found in os package type (dpkg) - curl (CVE-2019-5436 - https://security-tracker.debian.org/tracker/CVE-2019-5436)                                            warn
vulnerabilities        package MEDIUM Vulnerability found in os package type (dpkg) - python2.7-minimal (CVE-2019-9947 - https://security-tracker.debian.org/tracker/CVE-2019-9947)                               warn         
vulnerabilities        package MEDIUM Vulnerability found in os package type (dpkg) - python2.7-minimal (CVE-2019-9948 - https://security-tracker.debian.org/tracker/CVE-2019-9948)                               warn         
vulnerabilities        package MEDIUM Vulnerability found in os package type (dpkg) - unzip (CVE-2018-1000035 - https://security-tracker.debian.org/tracker/CVE-2018-1000035)                                     warn         
vulnerabilities        package HIGH Vulnerability found in os package type (dpkg) - libssh2-1 (fixed in: 1.7.0-1+deb9u1) - (CVE-2019-3855 - https://security-tracker.debian.org/tracker/CVE-2019-3855)            stop         
vulnerabilities        package HIGH Vulnerability found in os package type (dpkg) - libsystemd0 (fixed in: 232-25+deb9u10) - (CVE-2018-15686 - https://security-tracker.debian.org/tracker/CVE-2018-15686)        stop         
vulnerabilities        package HIGH Vulnerability found in os package type (dpkg) - libudev1 (fixed in: 232-25+deb9u10) - (CVE-2018-15686 - https://security-tracker.debian.org/tracker/CVE-2018-15686)           stop         

Image Digest: 
sha256:a2ca6b81deba65acb84362f105f829c9b015227271cffa82ecbd29c19bf3e917
Full Tag: anchore-engine:5000/example-image:latest
Status: fail
Last Eval: 2019-06-05T09:49:52Z
Policy ID: stop_high_and_critical_with_fix

En contraposición con el resultado de la fase only-critical, en este resultado aparecen bastantes vulnerabilidades, la mayoría de ellas con status warn y alguna con status stop, dando como resultado y status final stop. 

Estos dos ejemplos muestran la gran diferencia al aplicar distintas políticas a la misma imagen y la importancia de la política que usamos al leer los resultados que da la evaluación. Si se mira el primer resultado sin saber la política, se puede llegar a la errónea conclusión de que la imagen es perfecta y no contiene ninguna vulnerabilidad, mientras que en la segunda se ven vulnerabilidades que se pueden arreglar.

 

5.​ Añadir repositorios privados a Anchore

Además de poder descargar imágenes de repositorios públicos Anchore permite añadir las credenciales de un repositorio privado. Al ejecutar el comando add image, Anchore automáticamente intentará descargar la imagen de docker.io o de la url indicada en el comando, sin requerir ninguna configuración extra. Si esta descarga falla, Anchore mostrará un mensaje de error. Por ejemplo si ejecuto anchore-cli image add jesus12345/alpine-private-repo Anchore me devuelve:

Error: cannot fetch image digest/manifest from registry
HTTP Code: 400
Detail: {'error_codes': ['REGISTRY_PERMISSION_DENIED']}

El mensaje muestra que o bien el repositorio no existe o tiene el acceso prohibido por falta de credenciales. En este último caso, Anchore nos facilita el poder añadir las credenciales para que al intentar acceder, use la lista de credenciales que tenga que pertenezcan a ese dominio.

Para añadir las credenciales de un repositorio tan solo hay que ejecutar el comando

anchore-cli registry add “urlRepositorio” “usuario” “contraseña”

Por ejemplo para poder descargar la imagen que antes ha dado fallo he añadido las credenciales de mi repositorio de github

anchore-cli registry add docker.io jesus12345 ********

Se pueden mirar la URL, tipo y el usuario de cada repositorio que Anchore tiene guardado con

anchore-cli registry list

En el ejemplo anterior si ejecutamos el comando, el resultado es:

Registry         Type User              
docker.io        docker_v2 jesus12345

Ahora podemos añadir la imagen y Anchore la descarga del repositorio sin errores

 

6.​ Políticas para la evaluación de imágenes

Además de proporcionar información sobre una imagen, Anchore puede realizar una evaluación de la imagen según las políticas definidas por el usuario. 

Una política se compone de un conjunto de reglas que se utilizan para realizar una evaluación de una imagen de contenedor. Estas reglas pueden incluir comprobaciones de vulnerabilidades de seguridad, listas blancas y negras de imágenes, contenido del archivo de configuración, presencia de credenciales en la imagen, puertos expuestos u otras comprobaciones definidas por el usuario. Estas políticas pueden aplicarse globalmente o personalizarse para imágenes específicas o categorías de aplicaciones.

Los bundles (paquetes) son la unidad de definición y evaluación de políticas en Anchore. Un usuario puede tener varios bundle de políticas pero solo se usa una para la evaluación de una imagen, esta puede ser la que esté activa en el motor de Anchore al realizar el análisis o la que se indique en el inline scan.

Un bundle contiene cero o más políticas. Las políticas de un paquete definen las comprobaciones que deben realizarse contra una imagen y las acciones que se recomiendan si las comprobaciones encuentran una coincidencia.

Un bundle de políticas es un documento JSON compuesto por:

  • Políticas: reglas y acciones
  • Listas blancas: exclusiones de reglas para anular una coincidencia de alguna política
  • Mapeos: determinar qué políticas y listas blancas deben aplicarse a una imagen específica en el momento de la evaluación. De tal manera que podemos aplicar más o menos reglas según la imagen.
  • Lista blanca de imágenes: Imágenes que pasarán automáticamente la evaluación, sin importar si cumplen o no las políticas
  • Lista negra de imágenes: reemplaza las imágenes específicas para establecer de forma estática el resultado final en un error, independientemente del resultado de la evaluación de la política

 

​6.1.​ Política por defecto

Anchore cuenta con una política activada por defecto para poder ejecutar el análisis de imágenes sin tener que hacer ninguna configuración extra. Esta política comprueba que no haya ninguna vulnerabilidad alta o crítica, si la hay lo marca en los logs y hará que falle la integración continua si se está ejecutando el análisis en una fase. Las vulnerabilidades medias o bajas las marca con un warning, pero estas vulnerabilidades no harán fallar la integración continua.

Para poder saber qué política está usando Anchore, podemos listar las políticas que hay en anchore-cli, mostrando el id y si están o no activas con el comando:

anchore-cli policy list

Si queremos más información sobre una política en especial, podemos listar todos los datos de una política usando el Id de la política con el comando:

policy get 715a6056-87ab-49fb-abef-f4b4198c67bf --detail

 

6.2.​ Cómo crear una política propia y activarla

Para crear una política, necesitamos crear un bundle y activarlo. Al hacer una bundle propio de políticas hay que asegurarse que el ID principal del bundle no exista en la lista de políticas de Anchore y que los IDs internos de cada mapeo, policies y reglas no coincidan entre ellos porque dará fallo al intentar usarlo como política y Anchore usará la política por defecto.

Otra cosa importante a tener en cuenta es que el ID general del bundle puede ser cualquier cadena de caracteres, por ello aconsejo poner un nombre descriptivo para luego poder reconocer nuestro bundle por el ID fácilmente al listar las políticas poder diferenciarlas.

Cuidado, el ID no puede tener espacios en blanco o al ejecutar el comando para activar la política fallará aunque al crear el bundle no nos haya dado problema.

Este es un ejemplo de bundle que podemos aplicar para ignorar fallos de vulnerabilidades high que no tengan fix para poder pasar el umbral de calidad al analizar la imagen (la política por defecto no pasara el umbral si se descubre una vulnerabilidad high aunque no tenga fix).

{
   "blacklisted_images": [],
   "comment": "Personalized bundle ignoring unfixable vulnerabilities",
   "id": "stop_high_and_critical_with_fix",
   "mappings": [],
   "name": "Personalized bundle",
   "policies": [
       {
           "comment": "Personalized policy ignoring unfixable vulnerabilities",
           "id": "48e6f7d6-1765-11e8-b5f9-8b6f228548b6",
           "name": "IgnoreUnfixablePkgs",
           "rules": [
               {
                   "action": "STOP",
                   "gate": "vulnerabilities",
                   "id": "80569900-d6b3-4391-b2a0-bf34cf6d813d",
                   "params": [
                     { "name": "package_type", "value": "all" },
                     { "name": "severity_comparison", "value": ">" },
                     { "name": "severity", "value": "medium" },
                     { "name": "fix_available", "value": "true"}
                   ],
                   "trigger": "package"
                 }
           ],
           "version": "1_0"
       }
   ],
   "version": "1_0",
   "whitelisted_images": [],
   "whitelists": []
}

La parte importante es el objeto dentro de rules, donde definimos que se pare la ejecución si se encuentra una vulnerabilidad que cumpla con los parámetros definidos. 

Una vez tenemos el bundle listo se añade un bundle de una política

anchore-cli policy add bundle.json

El resultado del comando de arriba nos devolverá un id que es el que usamos para activar, si no se activa Anchore no la tendrá en cuenta al ejecutar el análisis

anchore-cli policy activate 2170857d-b660-4b56-a1a7-06550bf02eb2

Para más información sobre como crear una política: https://anchore.freshdesk.com/support/solutions/articles/36000074706-policies

 

6.3.​ Descargar y activar una política creada por la comunidad de Anchore

Anchore Policy Hub es un repositorio centralizado que ofrece una bundles con políticas predefinidas que están disponibles públicamente y pueden ser cargados / consumidos por Anchore. Este sistema sirve como un almacén de políticas para Anchore, donde bundles con políticas predefinidas se pueden buscar y descargar fácilmente, además de servir como un punto de partida para crear una políticas propia y como punto de encuentro donde los usuarios de Anchore puedan enviar y compartir nuevos paquetes de políticas.

Para poder usar Anchore Policy Hub solo hay que tener anchore-engine funcionando y anchore-cli con la versión 0.3.2 o superior.

Pasos para usar una política del hub:

  1. Comprobar la versión
anchore-cli --version

2. Mostrar las políticas disponibles en Anchore Policy Hub:

anchore-cli policy hub list
Name                           Description                                                         

anchore_security_only          Single policy, single whitelist bundle for performing               
                               security checks, including example blacklist known malicious        
                               packages by name.                                                   

anchore_default_bundle         Default policy bundle that comes installed with vanilla             
                               anchore-engine deployments.  Mixture of light vulnerability         
                               checks, dockerfiles checks, and warning triggers for common         
                               best practices.                                                     

anchore_cis_1.13.0_base        Docker CIS 1.13.0 image content checks, from section 4 and 5 
                               NOTE: some parameters (generally are named 'example...') must 
                               be modified as they require site-specific settings

3. Descargar una política del listado

anchore-cli policy hub get anchore_cis_1.13.0_base
Name: anchore_cis_1.13.0_base
Description: Docker CIS 1.13.0 image content checks, from section 4 and 5. NOTE: some parameters (generally are named 'example...') must be modified as they require site-specific settings

4. Instalar la política

anchore-cli policy hub install anchore_cis_1.13.0_base
Policy ID: anchore_cis_1.13.0_base
Active: False
Source: local
Created: 2019-01-31T18:42:50Z
Updated: 2019-01-31T18:42:50Z

5. Activar la política para que sea la que esté en uso

anchore-cli policy activate anchore_cis_1.13.0_base

6. Comprobar que la política se ha instalado correctamente y está activa

anchore-cli policy list
Policy ID: anchore_cis_1.13.0_base
Active: True
Source: local
Created: 2019-01-31T18:42:50Z
Updated: 2019-01-31T18:42:50Z

 

​7.​ Listado de comandos

Aqui podreis ver todos los comandos que más frecuentemente podréis usar junto con una breve explicación de lo que hacen:

Muestra todas las imágenes que se han analizado con Anchore y sobre las que puedes obtener información con image vuln

anchore-cli image list

Obtiene información resumen de la imagen, la misma que cuando se termina de ejecutar el comando anchore-cli image wait “nombreImagen” wait de la imagen

anchore-cli image get “nombreImagen”

Muestra la lista de sitios que proveen a Anchore la información sobre vulnerabilidades

anchore-cli system feeds list

Espera hasta que el motor y el servicio de Anchore este operativo, útil como primer comando en la integración continua para esperar a que se inicie todo antes de ejecutar un comando. Si no se usa podría suceder que se ejecute un comando de Anchore y de error por no haber esperado a que se inicialice

anchore-cli system wait

Añadir la imagen para que Anchore la analice, Anchore bajara del repositorio de docker hub si solo se especifica el nombre en vez de la url

anchore-cli image add “urlImagen/nombreImagen”

Muestra el contenido del tipo que se especifique, a elegir la lista de abajo.

anchore-cli image content “nombreImagen” “tipo”

Siendo tipo uno de estos posibles:

  • os: paquetes del sistema operativo de la imagen
  • files: sistema de ficheros de la imagen
  • npm: paquetes npm que la imagen contiene
  • gem: paquetes gem que la imagen contiene
  • python: paquetes python que la imagen contiene
  • java: paquetes java que la imagen contiene

 

Muestra información del bundle de políticas

anchore-cli policy hub get “nombrePolitica”

Muestra toda lista de políticas predefinidas por Anchore. anchore_default_bundle viene preinstalado para ejecutar la evaluación de imagen contra esa política

anchore-cli policy hub list

Instala el bundle de políticas, pero no las activa, solo puede haber una política activada

anchore-cli policy hub install “idPolitica”

Añade una política desde un fichero json

anchore-cli policy add “idPolitica”

Activa cualquier política de la lista de políticas disponibles, solo puede haber una política activa a la vez

anchore-cli policy activate “idPolitica”

Ejecutar comprobación de que la imagen cumple las políticas definidas y mostrar los detalles de las vulnerabilidades encontradas que han causado que la imagen sea suspendida en la evaluación.

anchore-cli evaluate check “nombreImagen” --detail

Añadir las credenciales de un repositorio

anchore-cli registry add “urlRepositorio” “usuario” “contraseña”

Borra las credenciales que Anchore tiene guardada bajo el nombre del registro

anchore-cli registry del “nombreRegistro”

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad