Differences

This shows you the differences between two versions of the page.

--- guia_rapida_de_la_linea_de_comandos_de_docker [2021/05/22 21:48] – busindre
+++ guia_rapida_de_la_linea_de_comandos_de_docker [2022/04/20 10:53] (current) – [SBOM de las imagenes de Docker] busindre
@@ Line 240: / Line 240: @@
-**TMPFS** (mount tmpfs filesystems)
+**TMPFS** (mount tmpfs filesystems).
-<code bash># Los parámetros usna la misma sintaxis que 'mount -t tmpfs -o'
-docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image</code>
+Se utiliza para almacenar información en memoria. Sólo mantiene la información mientras el contenedor esté en ejeución, práctico para almacenar información sensible no cifrada. A diferencia de volúmenes y bind mounts, donde es posible compartir la información entre contenedores, con tmpfs no lo es.
+<code bash># Los parámetros usan la misma sintaxis que 'mount -t tmpfs -o'
+docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image
+# Usando la sintaxis de mount.
+docker run -d --mount type=tmpfs,destination=/run my_image
+</code>
 **USER**: Seleccionar el UID/GID del proceso ejecutado dentro del contenedor.
@@ Line 263: / Line 268: @@
 **Montar una carpeta del host mediante "bind mount"**
-Los bind mounts es la forma antigua de guardar datos generados por contenedores, han existido desde los primeros días de Docker y desde hace ya mucho tiempo se recomienda no usarlos y usar los volúmenes. Los montajes Bind tienen una funcionalidad limitada y diferente en comparación con los volúmenes. Una limitación de los bind mounts es que NO pueden definir un propietario del directorio montado dentro del contenedor. Es decir, siempre se montará con el UID/GUIs del directorio del host. Eso en cambio si es algo configurable con los volúmenes. Siempre se puede usar desde la linea de comandos la opción %%--%%user para arrancar el contenedor con un determinado usuario del host y así poder tener acceso al bind mount desde el contenedor.
+Los bind mounts es la forma antigua de guardar datos generados por contenedores, han existido desde los primeros días de Docker y desde hace ya mucho tiempo se recomienda no usarlos y usar los volúmenes. Actualmente están regelados a entornos donde sea necesario acceder a determinada información del host anfitrión. Los bind mounts tienen una funcionalidad limitada y diferente en comparación con los volúmenes. Una limitación de los bind mounts es que NO pueden definir un propietario del directorio montado dentro del contenedor. Es decir, siempre se montará con el UID/GUIs del directorio del host. Eso en cambio si es algo configurable con los volúmenes. Siempre se puede usar desde la linea de comandos la opción %%--%%user para arrancar el contenedor con un determinado usuario del host y así poder tener acceso al bind mount desde el contenedor ([[permisos_y_propietarios_en_volumenes_con_docker-compose|leer]]) .
 Una diferencia con los volúmenes es que los montajes sobre directorios no vacíos, queda oculto el contenido previamente existente, cosa que no sucede al utilizar los volúmenes.
@@ Line 582: / Line 587: @@
 Por lo tanto una red puente unicamente tendrá una interfaz "br-xxxx" en el host, pero el host tendrá tantas interfaces veth como contenedores se tengan en dicha red (suponiendo que solo tienen una interfaz). Las interfaces virtuales en el host, el espacio de red y la conexión con la interfaz puente docker0 o br-XXXXX desparecen cuando el contenedor deja de estar activo.
+===== SBOM de las imagenes de Docker =====
+Una lista de materiales de software (SBOM) enumera todos los componentes que conforman un software (o que se utilizaron para construirlo). En el caso de imágenes de contenedores, esto incluye paquetes instalados (por ejemplo la bash, los certificados ca, git, etc) junto con sus dependencias, por ejemplo, Log4j. Cada herramienta SBOM puede incluir en su salida diferentes subconjuntos de esta información o incluso más detalles, como versiones de los componentes y su fuente. En Docker se puede usar el siguiente plugin para generar reportes [[https://github.com/docker/sbom-cli-plugin|sbom]], muy utiles a la hora de buscar aplicaciones vulnerables. Aunque si se quiere obtener más información se recomienda el uso de [[https://github.com/anchore/syft|syft]] directamente.
+<code bash>curl -sSfL https://raw.githubusercontent.com/docker/sbom-cli-plugin/main/install.sh | sh -s --
+docker sbom  XXXX</code>
+Ejemplo.
+<code bash>
+docker sbom zricethezav/gitleaks
+Syft v0.43.0
+ ✔ Loaded image
+ ✔ Parsed image
+ ✔ Cataloged packages      [49 packages]
+NAME                                VERSION                             TYPE
+alpine-baselayout                   3.2.0-r16                           apk
+alpine-keys                         2.3-r1                              apk
+apk-tools                           2.12.7-r0                           apk
+bash                                5.1.4-r0                            apk
+brotli-libs                         1.0.9-r5                            apk
+busybox                             1.33.1-r3                           apk
+ca-certificates                     20191127-r5                         apk
+ca-certificates-bundle              20191127-r5                         apk
+expat                               2.4.1-r0                            apk
+git                                 2.32.0-r0                           apk
+github.com/fsnotify/fsnotify        v1.4.9                              go-module
+github.com/gitleaks/go-gitdiff      v0.7.4                              go-module
+github.com/hashicorp/hcl            v1.0.0                              go-module
+github.com/magiconair/properties    v1.8.5                              go-module
+</code>
+Usando diferentes opciones de formato de salida se puede obtener más información, por ejemplo nombre, licencia, referencias externas, autor, etc.
+<code bash>
+docker sbom --format spdx zricethezav/gitleaks
+Syft v0.43.0
+ ✔ Loaded image
+ ✔ Parsed image
+ ✔ Cataloged packages      [49 packages]
+SPDXVersion: SPDX-2.2
+DataLicense: CC0-1.0
+SPDXID: SPDXRef-DOCUMENT
+DocumentName: zricethezav/gitleaks-latest
+DocumentNamespace: https://anchore.com/syft/image/zricethezav/gitleaks-latest-cafe4ad2-56b1-4618-8193-3c159f5832de
+LicenseListVersion: 3.16
+Creator: Organization: Anchore, Inc
+Creator: Tool: syft-[not provided]
+Created: 2022-04-20T08:48:22Z
+##### Package: alpine-baselayout
+PackageName: alpine-baselayout
+SPDXID: SPDXRef-Package-apk-alpine-baselayout-ed18f2a986e77aab
+PackageVersion: 3.2.0-r16
+PackageDownloadLocation: NOASSERTION
+FilesAnalyzed: false
+PackageLicenseConcluded: GPL-2.0-only
+PackageLicenseDeclared: GPL-2.0-only
+PackageCopyrightText: NOASSERTION
+ExternalRef: SECURITY cpe23Type cpe:2.3:a:alpine-baselayout:alpine-baselayout:3.2.0-r16:*:*:*:*:*:*:*
+ExternalRef: SECURITY cpe23Type cpe:2.3:a:alpine-baselayout:alpine_baselayout:3.2.0-r16:*:*:*:*:*:*:*
+ExternalRef: SECURITY cpe23Type cpe:2.3:a:alpine_baselayout:alpine-baselayout:3.2.0-r16:*:*:*:*:*:*:*
+ExternalRef: SECURITY cpe23Type cpe:2.3:a:alpine_baselayout:alpine_baselayout:3.2.0-r16:*:*:*:*:*:*:*
+ExternalRef: SECURITY cpe23Type cpe:2.3:a:alpine:alpine-baselayout:3.2.0-r16:*:*:*:*:*:*:*
+ExternalRef: SECURITY cpe23Type cpe:2.3:a:alpine:alpine_baselayout:3.2.0-r16:*:*:*:*:*:*:*
+ExternalRef: PACKAGE_MANAGER purl pkg:alpine/alpine-baselayout@3.2.0-r16?arch=x86_64&upstream=alpine-baselayout&distro=alpine-3.14.2
+...</code>