Configurando y asegurando el KUBE API SERVER

Desarrollo del tema

Auditoria de Kube API SERVER

La auditoría de Kubernetes proporciona un conjunto de registros cronológicos referentes a la seguridad que documentan la secuencia de actividades que tanto los usuarios individuales, como los administradores y otros componentes del sistema ha realizado en el sistema. Así, permite al administrador del clúster responder a las siguientes cuestiones:

¿qué ha pasado?
¿cuándo ha pasado?
¿quién lo ha iniciado?
¿sobre qué ha pasado?
¿dónde se ha observado?
¿desde dónde se ha iniciado?
¿hacia dónde iba?

KubeApiFlow

El componente Kube-apiserver lleva a cabo la auditoría. Cada petición en cada fase de su ejecución genera un evento, que se pre-procesa según un cierto reglamento y se escribe en un backend. Este reglamento determina lo que se audita y los backends persisten los registros. Las implementaciones actuales de backend incluyen los archivos de logs y los webhooks.

Cada petición puede grabarse junto con una "etapa" asociada. Las etapas conocidas son:

RequestReceived - La etapa para aquellos eventos generados tan pronto como el responsable de la auditoría recibe la petición, pero antes de que sea delegada al siguiente responsable en la cadena.
ResponseStarted - Una vez que las cabeceras de la respuesta se han enviado, pero antes de que el cuerpo de la respuesta se envíe. Esta etapa sólo se genera en peticiones de larga duración (ej. watch).
ResponseComplete - El cuerpo de la respuesta se ha completado y no se enviarán más bytes.
Panic - Eventos que se generan cuando ocurre una situación de pánico.

Nota: La característica de registro de auditoría incrementa el consumo de memoria del servidor API porque requiere de contexto adicional para lo que se audita en cada petición. De forma adicional, el consumo de memoria depende de la configuración misma del registro. ApiAuditImplementation

Reglamento de Auditoría

datos que deberían incluir. La estructura del objeto de reglas de auditoría se define en el audit.k8s.io grupo de API. Cuando se procesa un evento, se compara con la lista de reglas en orden. La primera regla coincidente establece el "nivel de auditoría" del evento. Los niveles de auditoría conocidos son:

None - no se registra eventos que disparan esta regla.
Metadata - se registra los metadatos de la petición (usuario que la realiza, marca de fecha y hora, recurso, verbo, etc.), pero no la petición ni el cuerpo de la respuesta.
Request - se registra los metadatos del evento y el cuerpo de la petición, pero no el cuerpo de la respuesta. Esto no aplica para las peticiones que no son de recurso.
RequestResponse - se registra los metadatos del evento, y los cuerpos de la petición y la respuesta. Esto no aplica para las peticiones que no son de recurso.

Es posible indicar un archivo al definir el reglamento en el kube-apiserver usando el parámetro --audit-policy-file. Si dicho parámetros se omite, no se registra ningún evento.

Backends de auditoría

Los backends de auditoría persisten los eventos de auditoría en un almacenamiento externo. El Kube-apiserver por defecto proporciona tres backends:

Backend de logs, que escribe los eventos en disco
Backend de webhook, que envía los eventos a una API externa
Backend dinámico, que configura backends de webhook a través de objetos de la API AuditSink.

KubeAuditArchitecture

Backend de Logs

El backend de logs escribe los eventos de auditoría a un archivo en formato JSON. Puedes configurar el backend de logs de auditoría usando el siguiente parámetro de kube-apiserver flags:

--audit-log-path especifica la ruta al archivo de log que el backend utiliza para escribir los eventos de auditoría. Si no se especifica, se deshabilita el backend de logs. - significa salida estándar
--audit-log-maxage define el máximo número de días a retener los archivos de log
--audit-log-maxbackup define el máximo número de archivos de log a retener
--audit-log-maxsize define el tamaño máximo en megabytes del archivo de logs antes de ser rotado

Backend de Webhook

El backend de Webhook envía eventos de auditoría a una API remota, que se supone es la misma API que expone el kube-apiserver. Puedes configurar el backend de webhook de auditoría usando los siguientes parámetros de kube-apiserver:

--audit-webhook-config-file especifica la ruta a un archivo con configuración del webhook. La configuración del webhook es, de hecho, un archivo kubeconfig.
--audit-webhook-initial-backoff especifica la cantidad de tiempo a esperar tras una petición fallida antes de volver a intentarla. Los reintentos posteriores se ejecutan con retraso exponencial.

El archivo de configuración del webhook usa el formato kubeconfig para especificar la dirección remota del servicio y las credenciales para conectarse al mismo.

En la versión 1.13, los backends de webhook pueden configurarse dinámicamente.

KubeApiServer

Laboratorio: Configuración de auditoria

Descripción

El sistema de auditoría es crucial para contar con el historial de cambios de recursos de kubernetes asociados a namespaces o grupos de recursos de kubernetes en específico, tomando en consideración que entre más recursos se auditen, se requerirá mayor cantidad de recursos de hardware en nodos masters.

Objetivos

Implementar sistema de auditoría en ambiente de rke desde el archivo cluster.yaml

Antes de comenzar

Contar con el acceso al ambiente del laboratorio.

Conexión hacia cluster

Ingrese al cluster asignado con las credenciales proporcionadas.

Configure la variable KUBECONFIG.

export KUBECONFIG=~/devcluster/kube_config_cluster.yml

Verifique el acceso mediante comandos.
```
kubectl get namespaces
```

Inicio de laboratorio

Debajo de la sección de kube-api en el archivo cluster.yaml, agregar lo siguiente para habilitar el sistema de auditoría

    audit_log:
      enabled: true
      configuration:
        max_age: 6
        max_backup: 6
        max_size: 110
        path: /var/log/kube-audit/audit-log.json
        format: json
        policy:
          apiVersion: audit.k8s.io/v1
          kind: Policy
          rules:
            - level: RequestResponse
              resources:
                - group: ""
                  resources:
                    - namespaces
            - level: RequestResponse
              resources:
                - group: ""
                  resources:
                    - pods
              namespaces:
                - dev
            - level: Metadata
              resources:
                - group: "apps"
                  resources:
                    - deployments
                - group: ""
                  resources:
                    - secrets
                    - configmaps
                    - services
                    - serviceaccounts
            - level: Metadata

Iniciar nuevamente rke para leer la nueva configuración.
```
rke up
```
Nota Si muestra algún error, validar la indentación del archivo
Identificar el proceso de ejecución de kube-apiserver
```
ps -aux |grep kube-api
```
Identificar el archivo de configuración de políticas de auditoria en el proceso de kube-apiserver
```
ps -aux |grep kube-api |grep audit-policy-file
```
Identificar el archivo de logs en el proceso de kube-apiserver
```
ps -aux |grep kube-api |grep audit-policy-file
```

Revisar logs de audit

tail -f /var/log/kube-audit/audit-log.json

Crear namespace llamado dev
```
kubectl create ns dev
```
Revisar que se haya auditado la creación de dicho namespace en el log.
```
sudo grep '"resource":"namespaces","name":"dev"' /var/log/kube-audit/audit-log.json |grep create
```
- Debido a que el log almacena la información en formato JSON, es posible revisar la información con alguna herramienta para la lectura de JSON con jq o páginas webs como Code Beautify.
Crear namespace llamado qa
```
kubectl create ns qa
```

Revisar que se haya auditado la creación de dicho namespace en el log

sudo grep '"resource":"namespaces","name":"qa"' /var/log/kube-audit/audit-log.json |grep create

Crear un pod en el namespace dev

kubectl run pod-with-audit --image nginx -n dev

Revisar logs de pod creado en namespace dev

sudo grep 'pod-with-audit' /var/log/kube-audit/audit-log.json

Crear un pod en el namespace qa

kubectl run pod-without-audit --image nginx -n qa

Revisar logs de pod creado en namespace qa
```
sudo grep 'pod-without-audit' /var/log/kube-audit/audit-log.json
```
NOTA En el log se encuentra únicamente información de los pods del namespace dev y no de qa debido a que en el Policy se indicó que auditarán unicamente los pods de dicho namespace
Limpiamos el ambiente.
Borrar namespace de dev
```
kubectl delete ns dev
kubectl delete ns qa
```
Debido a alto consumo de recursos del componente de audit se borrará la sección agregada al archivo cluster.yaml
```
vi cluster.yaml
rke up
```