Crear una política de auditoría de Kubernetes
A medida que aumenta la popularidad de Kubernetes, la auditoría de Kubernetes es una fuente crucial de datos para incorporar en su estrategia de seguridad de Kubernetes. Le da a los equipos de seguridad y DevOps una transparencia completa en todas las operaciones que tienen lugar dentro del clúster. La funcionalidad de registro de auditoría se introdujo en Kubernetes 1.11. Auditar registros es una parte esencial para proteger su clúster de Kubernetes, ya que registran los eventos como iniciar un servicio de puerto de nodo, eliminar espacios de nombres y lanzar nuevas implementaciones. Este blog explica en detalle cuál es la auditoría de Kubernetes y le proporciona información que lo ayuda a comenzar. Antes de pasar a la política de auditoría en Kubernetes, primero definamos qué es la auditoría.
¿Qué es auditar en Kubernetes??
Utilizando la auditoría de Kubernetes, la historia de eventos de un clúster se captura en una serie de registros que se organizan cronológicamente. El plano de control en sí, las aplicaciones que utilizan la API de Kubernetes y los usuarios, todos ellos proporcionan actividades que el clúster audita.
Los administradores de clúster pueden utilizar la auditoría para proporcionar respuestas a algunas preguntas como lo que ocurrió y cuándo ocurrió, quién lo inició, lo que ocurrió, donde se observó, dónde se originó y hacia dónde se revela todos los que se revelan.
La vida útil de los registros de auditoría comienza con el componente de Kube-APISERVER. Cada solicitud proporciona un evento de auditoría en cada paso de procesamiento, que luego se procesa previamente en línea con una política y se guarda en un backend. La política determina lo que se registra y los backends mantienen los registros. Dos de las implementaciones de backend actuales son archivos de registro y webhooks.
Cada solicitud se puede colocar en una etapa particular. Las etapas y su descripción se representan en lo siguiente:
| Nombre escénico | Descripción de la etapa |
|---|---|
| Solicitud recibida | La solicitud es recibida por el controlador de auditoría. |
| Responsado | Aunque el cuerpo de respuesta no se transmite, los encabezados de respuesta permanecen. |
| Respuesta completa | No se transfieren bytes adicionales una vez que se envía el cuerpo de respuesta. |
| Pánico | La solicitud no tuvo éxito debido a un error de servidor interno. |
¿Cuál es la política de auditoría en Kubernetes??
La política de auditoría especifica los estándares para los eventos que deben informarse y los datos que deben proporcionar. El formato de objeto de política de auditoría se especifica mediante la auditoría.K8S.Grupo de API de IO. Se compara una lista de reglas con un evento cuando se procesa de manera ordenada. El nivel de auditoría del evento se decide con la primera regla coincidente.
Ninguno, MetDT, Solicilia y RequestResponse son los niveles de auditoría que se especifican.
| Ninguno | Los eventos que cumplan con este requisito no deben registrarse. |
|---|---|
| Metadatos | Los cuerpos de solicitud y respuesta no están registrados; Solo la información de solicitud (solicitar usuario, recurso, verbo, etc.). |
| Pedido | El cuerpo de solicitud y los datos del evento están registrados, pero no el cuerpo de respuesta. |
| Solicitar respuesta | Los organismos de solicitud y respuesta, así como los metadatos del evento, deben documentarse. Las solicitudes que no están relacionadas con los recursos no están cubiertas por esto. |
Un archivo que contiene la política se puede pasar a Kube-APISERVER utilizando el interruptor de archivo-Audit-Policy. Si la bandera no está establecida, no se registran eventos en absoluto. El campo de reglas del archivo de política de auditoría debe estar llenado. Una política se considera ilegal si no contiene regulaciones.
Aquí hay un ejemplo de un archivo de política de auditoría para su ayuda. Aquí, puede ver toda la información, como usuarios, grupos, recursos y otras cosas.
Recuerde que los registros de auditoría se recopilan en función de la política de auditoría configurada antes de intentar comprender la política de auditoría que se proporciona a continuación. Los eventos y la información que deben registrarse son especificados por la política de auditoría. La primera regla coincidente en la jerarquía de las reglas que se especifican en la política de auditoría determina el nivel de auditoría del evento.
Adjunto hay un archivo de política de auditoría de muestra completo al que puede consultar comprender mejor los detalles.
El archivo de política de auditoría de Kubernetes para los clústeres de GKE comienza con las reglas que describen qué eventos no deben registrarse en absoluto. Por ejemplo, esta regla especifica que los recursos de los nodos o los recursos nodestatus no deben informar ninguna solicitud realizada por Kubelets. Recuerde que si el nivel es ninguno, no se deben informar eventos coincidentes.
El archivo de política contiene una lista de reglas que son instancias especiales después de la lista de niveles de ninguna regla. Como ejemplo, esta regla de caso especial instruye a registrar las solicitudes específicas en el nivel de metadatos.
Un evento coincide con la regla si todos los siguientes son verdaderos:
- Ninguna regla anterior en el archivo de política coincide con el evento.
- Un recurso de los Secretos, ConfigMaps o TokenReviews Tipos es el tema de la solicitud.
- La etapa de llamada de la llamada no está cubierta por el evento.
El archivo de política luego contiene una colección de reglas generales que siguen la lista de reglas de casos especiales. Debe cambiar el valor de $ (conoce_apis) al valor de las API conocidas para ver las reglas generales del script. Después de la sustitución, aparece una regla que se lee de la siguiente manera:
Puede registrar cada solicitud a nivel de metadatos utilizando un archivo de política de auditoría simple.
¿Qué son los registros de auditoría y por qué debería configurarlos?
Los registros de auditoría son muy útiles en un clúster de Kubernetes para rastrear y rastrear las actividades y cambios en varios recursos de clúster. Puede averiguar quién realizó qué y cuándo habilitando la auditoría, que no está habilitado de forma predeterminada.
Los registros de auditoría sirven como base para la seguridad y el cumplimiento y ofrece una idea de las actividades que tienen lugar en un clúster de Kubernetes. Puede detectar instantáneamente cualquier comportamiento inusual que ocurra en su clúster, como intentos de inicio de sesión fallidos o intentos de acceder a secretos confidenciales, con registro de auditoría correctamente configurado. Puede colaborar en los silos para responder rápidamente a actividades sospechosas empleando auditorías. La implementación de la endurecimiento por clúster y la mitigación de cualquier configuración errónea se ve afectada por la auditoría de rutina de los datos de registro de eventos.
Conclusión
Aprendimos para qué sirven exactamente los registros de auditoría de Kubernetes y para qué se usan. También aprendimos por qué la auditoría es crucial para la seguridad de su clúster Kubernetes. También se discute la necesidad de activar los registros de auditoría para su clúster Kubernetes. Para su referencia, proporcionamos un archivo de política de auditoría de muestra y una explicación detallada del contenido. Puede consultar este artículo si es nuevo en este concepto.