Ahora es un requisito que los clústeres ejecuten Kubernetes >=1.19.

Las etiquetas de anulación con anotaciones kubernetes.io no registradas serán obsoletas. Pronto será un requisito usar kubeaudit.io en su lugar. Consulte esta discusión para obtener más contexto.

🚨 Aviso de desaprobación 🚨

Kubeaudit está planificado para ser desaprobado para octubre de 2024.

Estamos buscando activamente mantenedores interesados en asumir la responsabilidad de este proyecto. Si le apasiona continuar con su desarrollo y mantenimiento, comuníquese con nosotros.

Para los usuarios que buscan alternativas, recomendamos la transición a Kubebench, que ofrece funcionalidad similar y se mantiene activamente.

Gracias a la comunidad por sus contribuciones y apoyo.

kubeaudit ☁️ 🔒 💪

kubeaudit es una herramienta de línea de comandos y un paquete Go para auditar clústeres de Kubernetes en busca de diversas preocupaciones de seguridad, como:

• ejecutar como no root
• usar un sistema de archivos raíz de solo lectura
• eliminar capacidades peligrosas, no agregar nuevas
• no ejecutar como privilegiado
• ¡y más!

Resumen: kubeaudit asegura que despliegues contenedores seguros!

Package

Para usar kubeaudit como un paquete Go, consulte la documentación del paquete.

El resto de este README se centrará en cómo usar kubeaudit como una herramienta de línea de comandos.

Interfaz de Línea de Comandos (CLI)

• Instalación
• Inicio Rápido
• Resultados de la Auditoría
• Comandos
• Archivo de Configuración
• Anular Errores
• Contribuyendo

Instalación

Brew

brew install kubeaudit

Descargar un binario

Kubeaudit tiene lanzamientos oficiales que están bendecidos y son estables: Lanzamientos oficiales

Compilación propia

La rama principal puede tener características más nuevas que las versiones estables. Si necesita una característica nueva que aún no está incluida en un lanzamiento, asegúrese de usar la última versión de Go y ejecute lo siguiente:

go get -v github.com/Shopify/kubeaudit

Comience a usar kubeaudit con el Inicio Rápido o vea todos los comandos compatibles.

Plugin de Kubectl

Requisito previo: kubectl v1.12.0 o posterior

Con kubectl v1.12.0 que introduce la fácil integración de funciones externas, kubeaudit se puede invocar como kubectl audit mediante

• ejecutar make plugin y tener $GOPATH/bin disponible en su PATH.

o

• renombrar el binario a kubectl-audit y tenerlo disponible en su PATH.

Docker

Ya no publicamos imágenes en Docker Hub (desde que Docker Hub eliminó las organizaciones Free Team). Por el momento, las imágenes antiguas aún están disponibles pero pueden dejar de estarlo en cualquier momento. Pronto comenzaremos a publicar imágenes en el registro de contenedores de Github.

Para ejecutar kubeaudit como un trabajo en su clúster, consulte Ejecutar kubeaudit en un clúster.

Inicio Rápido

kubeaudit tiene tres modos:

1. Modo Manifiesto
2. Modo Local
3. Modo Clúster

Modo Manifiesto

Si se proporciona un archivo de manifiesto de Kubernetes usando la bandera -f/--manifest, kubeaudit auditará el archivo de manifiesto.

Ejemplo de comando:

kubeaudit all -f "/path/to/manifest.yml"

Ejemplo de salida:

$ kubeaudit all -f "internal/test/fixtures/all_resources/deployment-apps-v1.yml"

---------------- Results for ---------------

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: deployment
    namespace: deployment-apps-v1

--------------------------------------------

-- [error] AppArmorAnnotationMissing
   Message: AppArmor annotation missing. The annotation 'container.apparmor.security.beta.kubernetes.io/container' should be added.
   Metadata:
      Container: container
      MissingAnnotation: container.apparmor.security.beta.kubernetes.io/container

-- [error] AutomountServiceAccountTokenTrueAndDefaultSA
   Message: Default service account with token mounted. automountServiceAccountToken should be set to 'false' or a non-default service account should be used.

-- [error] CapabilityShouldDropAll
   Message: Capability not set to ALL. Ideally, you should drop ALL capabilities and add the specific ones you need to the add list.
   Metadata:
      Container: container
      Capability: AUDIT_WRITE
...

Si no se encuentran errores con una severidad mínima determinada, se devuelve lo siguiente:

All checks completed. 0 high-risk vulnerabilities found

Corrección automática

El modo manifiesto también admite la corrección automática de todos los problemas de seguridad usando el comando autofix:

kubeaudit autofix -f "/path/to/manifest.yml"

Para escribir el manifiesto corregido en un nuevo archivo en lugar de modificar el archivo fuente, use la bandera -o/--output.

kubeaudit autofix -f "/path/to/manifest.yml" -o "/path/to/fixed"

Para corregir un manifiesto basado en reglas personalizadas especificadas en un archivo de configuración de kubeaudit, use la bandera -k/--kconfig.

kubeaudit autofix -k "/path/to/kubeaudit-config.yml" -f "/path/to/manifest.yml" -o "/path/to/fixed"

Modo Clúster

Kubeaudit puede detectar si se está ejecutando dentro de un contenedor en un clúster. Si es así, intentará auditar todos los recursos de Kubernetes en ese clúster:

kubeaudit all

Modo Local

Kubeaudit intentará conectarse a un clúster usando el archivo kubeconfig local ($HOME/.kube/config). Se puede especificar una ubicación diferente de kubeconfig usando la bandera --kubeconfig. Para especificar un contexto del kubeconfig, use la bandera -c/--context.

kubeaudit all --kubeconfig "/path/to/config" --context my_cluster

Para obtener más información sobre los archivos de configuración de Kubernetes, consulte https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/

Resultados de la Auditoría

Kubeaudit genera resultados con tres niveles de severidad:

• Error: Un problema de seguridad o configuración de Kubernetes inválida
• Warning: Una recomendación de mejor práctica
• Info: Informativo, no se requiere acción. Esto incluye resultados que han sido anulados

El nivel de severidad mínimo se puede configurar usando la bandera --minSeverity/-m.

Por defecto, kubeaudit mostrará los resultados de forma legible para humanos. Si se pretende procesar la salida adicionalmente, se puede configurar para que genere JSON usando la bandera --format json. Para generar resultados como registros (el valor predeterminado anterior) use --format logrus. Algunos formatos de salida incluyen colores para facilitar la lectura de los resultados en una terminal. Para deshabilitar los colores (por ejemplo, si está enviando la salida a un archivo de texto), puede usar la bandera --no-color.

Puede generar un informe de kubeaudit en SARIF usando la bandera --format sarif. Para escribir los resultados SARIF en un archivo, puede redirigir la salida con >. Por ejemplo:

kubeaudit all -f path-to-my-file.yaml --format="sarif" > example.sarif

Si hay resultados de nivel de severidad error, kubeaudit saldrá con el código de salida 2. Esto se puede cambiar usando la bandera --exitcode/-e.

Para todas las formas en que se puede personalizar kubeaudit, consulte Banderas Globales.

Comandos

Auditores

Los auditores también se pueden ejecutar individualmente.

Banderas Globales

Archivo de Configuración

El archivo de configuración de kubeaudit se puede usar para dos propósitos:

1. Habilitar solo algunos auditores
2. Especificar configuración para auditores

Cualquier configuración que se pueda especificar usando banderas para los auditores individuales se puede representar usando el archivo de configuración.

El archivo de configuración tiene el siguiente formato:

enabledAuditors:
  # Los auditores están habilitados por defecto si no se establecen explícitamente en "false"
  apparmor: false
  asat: false
  capabilities: true
  deprecatedapis: true
  hostns: true
  image: true
  limits: true
  mounts: true
  netpols: true
  nonroot: true
  privesc: true
  privileged: true
  rootfs: true
  seccomp: true
auditors:
  capabilities:
    # agregar capacidades necesarias a la lista de agregar, para que kubeaudit no reporte errores
    allowAddList: ['AUDIT_WRITE', 'CHOWN']
  deprecatedapis:
    # Si no se especifican versiones y el auditor 'deprecatedapis' está habilitado, se generarán resultados
    # WARN para los recursos definidos con una API obsoleta.
    currentVersion: '1.22'
    targetedVersion: '1.25'
  image:
    # Si no se especifica una imagen y el auditor 'image' está habilitado, se generarán resultados
    # WARN para contenedores que usan una imagen sin etiqueta
    image: 'myimage:mytag'
  limits:
    # Si no se especifican límites y el auditor 'limits' está habilitado, se generarán resultados
    # WARN para contenedores que no tienen límites de cpu o memoria especificados
    cpu: '750m'
    memory: '500m'

Para obtener más detalles sobre cada auditor, incluyendo una descripción de la configuración específica del auditor en el archivo de configuración, consulte la Documentación de Auditores.

Nota: El archivo de configuración de kubeaudit no es lo mismo que el archivo kubeconfig especificado con la bandera --kubeconfig, que se refiere al archivo de configuración de Kubernetes (consulte Modo Local). También tenga en cuenta que solo los comandos all y autofix admiten el uso de un archivo de configuración de kubeaudit. No funcionará con otros comandos.

Nota: Si se usan banderas en combinación con el archivo de configuración, las banderas tendrán prioridad.

Anular Errores

Los problemas de seguridad se pueden ignorar para contenedores o pods específicos agregando etiquetas de anulación. Esto significa que el auditor producirá resultados info en lugar de resultados error y el nombre del resultado de la auditoría tendrá Allowed añadido. Las etiquetas están documentadas en la documentación de cada auditor, pero el formato general para los auditores que admiten anulaciones es el siguiente:

Una etiqueta de anulación consiste en una clave y un valor.

La clave es una combinación del tipo de anulación (contenedor o pod) y un identificador de anulación que es único para cada auditor (consulte la documentación del auditor específico). La clave puede tomar una de dos formas dependiendo del tipo de anulación:

1. Anulaciones de contenedor, que anulan el auditor para ese contenedor específico, se formatean de la siguiente manera:

container.kubeaudit.io/[nombre del contenedor].[identificador de anulación]

2. Anulaciones de pod, que anulan el auditor para todos los contenedores dentro del pod, se formatean de la siguiente manera:

kubeaudit.io/[identificador de anulación]

Si el valor se establece en una cadena no vacía, se mostrará en el resultado info como OverrideReason:

$ kubeaudit asat -f "auditors/asat/fixtures/service-account-token-true-allowed.yml"

---------------- Results for ---------------

  apiVersion: v1
  kind: ReplicationController
  metadata:
    name: replicationcontroller
    namespace: service-account-token-true-allowed

--------------------------------------------

-- [info] AutomountServiceAccountTokenTrueAndDefaultSAAllowed
   Message: Audit result overridden: Default service account with token mounted. automountServiceAccountToken should be set to 'false' or a non-default service account should be used.
   Metadata:
      OverrideReason: SomeReason

Según la especificación de Kubernetes, value debe tener 63 caracteres o menos y debe estar vacío o comenzar y terminar con un carácter alfanumérico ([a-z0-9A-Z]) con guiones (-), guiones bajos (_), puntos (.), y alfanuméricos en medio.

Se pueden agregar múltiples etiquetas de anulación (para múltiples auditores) al mismo recurso.

Consulte la documentación del auditor específica que desea anular para ver ejemplos.

Para obtener más información sobre las etiquetas, consulte https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

Contribuyendo

Si desea corregir un error, contribuir con una característica o simplemente corregir un error tipográfico, siéntase libre de hacerlo siempre que siga nuestro Código de Conducta.

1. ¡Cree su propio fork!
2. Obtenga el código fuente: go get github.com/Shopify/kubeaudit
3. Vaya al código fuente: cd $GOPATH/src/github.com/Shopify/kubeaudit
4. Agregue su repositorio fork como fork: git remote add fork https://github.com/you-are-awesome/kubeaudit
5. Cree su rama de características: git checkout -b awesome-new-feature
6. Instale Kind
7. Ejecute las pruebas para ver que todo funciona como se espera: USE_KIND=true make test (para ejecutar pruebas sin Kind: make test)
8. Confirme sus cambios: git commit -am 'Adds awesome feature'
9. Empuje a la rama: git push fork
10. Firme el Acuerdo de Licencia del Colaborador
11. Envíe un PR (Todos los PR deben estar etiquetados con 🐛 (Corrección de errores), ✨ (Nueva característica), 📖 (Actualización de documentación), o ⚠️ (Cambios importantes) )
12. ???
13. Benefíciese

Tenga en cuenta que si no firmó el CLA antes de abrir su PR, puede volver a ejecutar la verificación agregando un comentario al PR que diga "I've signed the CLA!"!