Introducción

A continuación vamos a ver algunos conceptos a tener claros para cuando operemos sobre el cluster.

Componentes

• Componentes encargados de la autenticación y autorización de los tres tipos de acceso al cluster que hay en la plataforma: APIserver, Aplicaciones de administración y Aplicaciones de usuario
• Componentes encargados de la gestión y custodia de los secretos utilizados por los servicios gestionados por KEOS
• LDAP¹ y Kerberos² Internos
• Políticas de Seguridad del Cluster

1 LDAP(Lightweight Directory Access Protocol). El protocolo ligero de acceso a directorios hace 
referencia a un protocolo a nivel de aplicación que permite el acceso a un servicio de directorio 
ordenado y distribuido para buscar diversa información en un entorno de red
2 Kerberos. Kerberos es un protocolo de autenticación de redes de ordenador creado 
por el MIT que permite a dos ordenadores en una red insegura demostrar su identidad mutuamente de manera segura.

Autorización y autenticación

A continuación nos centraremos en la autenticación y autorización de los tres tipos de acceso al cluster que hay en la plataforma:

• 2.1. API Server
• 2.2. Autenticación de aplicaciones de administración
• 2.3. Aplicaciones de Usuario

Adicionalmente mencionaremos también la autorización en lo que se refiere a datos

• 2.4. Autorización del Dato

API Server

El API Server se ejecuta en los nodos de tipo control-plane utilizando el puerto 6443. Los clientes pueden autenticarse de dos formas:

• Con un certificado X509 válido para el API Server: estos certificados se validarán con la CA configurada en el instalador, pero se deja su emisión en manos de la gestión de la infraestructura.

• Con un ServiceAccount Token orientado a aplicaciones internas del cluster. Todos los Pods que corren en el sistema tienen:
• Una Service Account asociada, que se usa en K8s para proporcionar una identidad a los pods. Todo Pod que quiera interaccionar con el API Server deberá autenticarse con un particular ServiceAccount, que si no se especifica, será la que hay por defecto del Namespace.
• Un token disponible dentro de los contenedores con el que pueden autenticarse en el API Server, usando como nombre de usuario

		
		“system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)”
				y grupos “system:serviceaccounts”
				y “system:serviceaccounts:(NAMESPACE)”.
		
        

• Con un token OIDC para usuarios del IdP configurado en el cluster: mediante un flujo OIDC, se podrán intercambiar las credenciales del IdP por un 'id_token' y autenticarse con él en el API Server (se tendrán en cuenta tanto el usuario como sus grupos). El plugin de kubectl "kubelogin" utiliza el Authorization Code Grant y permite una autenticación transparente con el API Server a partir de un login en la web, almacenando el 'id_token' en caché local y utilizando el 'refresh_token' para su renovación.

Autenticación de aplicaciones de administración

La autenticación de UIs de administración de Stratio KEOS (Stratio GoSec y Stratio Command Center) se apoya en el single sign-on de la plataforma, compuesto por nginx-ingress-controller, oauth2-proxy y Stratio Identity Server (SIS):

• El ingress-nginx permite configurar los objetos Ingress con anotaciones, y entre todas las opciones que ofrece se pueden encontrar encontrar unas específicas para autenticación externa con las que gestionar la validación de las peticiones y el inicio del flujo OAuth2². Este proxy añade a las peticiones la cookie de Stratio (JWT) con la información del usuario.
• El oauth2-proxy, un proxy inverso con capacidades de Oauth2 e integración con múltiples proveedores, añade la integración con el SIS.
• El SIS, basado en el Central Authentication Service (CAS) de Apereo, es quien gestiona las identidades del idP¹ y la capa de SSO.

El flujo completo queda de la siguiente forma:

5 Single sign-on (SSO) o autenticación única, 
es un procedimiento de autenticación que habilita a un usuario
determinado para acceder a varios sistemas con una sola instancia de identificación.
6 OAuth2 es el protocolo estándar de la industria para la autorización. 
OAuth 2.0 se centra en la simplicidad del desarrollador del cliente al tiempo
que proporciona flujos de autorización específicos para aplicaciones web, 
aplicaciones de escritorio, teléfonos móviles y dispositivos de sala de estar.

Aplicaciones de Usuario

Como aplicaciones de usuario (desplegadas en tenants) se encuentran las aplicaciones de cliente y las aplicaciones no-administrativas de Stratio. Para estas aplicaciones se brinda la posibilidad de integración directa con el SIS como clientes Oauth. Este es el método utilizado por las aplicaciones no-administrativas de Stratio como Stratio Rocket o Stratio Discovery.

La autorización para estas aplicaciones de cliente queda delegada al propio servicio, quien podrá utilizar la información del usuario obtenida en la fase de autenticación.

Opcionalmente, al igual que para las interfaces de usuario de administración, una aplicación puede hacer uso del flujo de OAuth descrito sin ser cliente OAuth, sino simplemente indicando en las anotaciones de su objeto Ingress las URL del oauth2_proxy, lo que hará que el servicio reciba una cookie con la información del usuario. La autorización para estas aplicaciones de cliente queda delegada al propio servicio, quien podrá utilizar la información del usuario obtenida en la fase de autenticación

Autorización del Dato

La plataforma cuenta con el servicio de Stratio GoSec, que aporta la capacidad de autorización del dato. Todos los data stores de Stratio utilizan este autorizador para perfilar los accesos.

El servicio de Stratio GoSec se compone de una capa de negocio (BaaS¹) delante de sus API de administración y gestionable por una interfaz de usuario, una capa de datos (DaaS) para gestión de identidades y servicios, y el propio servicio de autorización. El despliegue de Stratio GoSec se incluye en el proceso de instalación del cluster y su interfaz de usuario se expone con el método descrito en UIs de administración.

La interfaz de usuario de Stratio GoSec permite la creación y actualización de políticas de acceso, además de grupos y usuarios internos, así como ver y eliminar servicios del tenant.

Los usuarios, grupos y servicios pueden asignarse a las políticas para permitir o denegar diferentes acciones en los recursos del servicio, siendo un recurso cualquier objeto autorizable que defina el plugin o agente de autorización del servicio (un topic de Kafka, una columna o esquema de una base de datos, un workflow de Stratio Rocket, etc.).

• Los plugins son programas que se ejecutan en la tecnología a autorizar, y se encargan de realizar las llamadas al autorizador para cada petición recibida.
• Los agentes son aplicaciones que acompañan a estas tecnologías sincronizando el modelo de autorización en Stratio GoSec con su autorización nativa.

Por defecto, y salvo que haya una política que indique lo contrario, todas las acciones sobre cualquier recurso están denegadas para todos los usuarios y grupos.

Como se ha mencionado, keos-installer despliega Stratio GoSec utilizando Charts de Helm.

1 Backend as a service (BaaS), también conocido como “mobile backend as a service”,
es un modelo para proporcionar a los desarrolladores web y de aplicaciones móviles 
una forma de vincular estas aplicaciones al almacenamiento en la nube, servicios 
analíticos y/o otras características tales como la gestión de usuarios, 
la posibilidad de enviar  notificaciones push y la integración con servicios 
en redes sociales.

Video: Seguridad, Autenticación y Secretos

Gestión y Custodia de Secretos

Para el almacenamiento de secretos con alto nivel de seguridad se despliega Vault, una herramienta sin competencia en el mercado para acceso seguro a los secretos por su criptografía, estrategias y funcionalidades.

Además del almacenamiento de secretos con encriptación previa a la escritura, secretos dinámicos, encripción al vuelo, mecanismo de asignación de recursos y renovación de secretos y revocación, en Stratio KEOS se utiliza la PKI Engine de Vault y un Kerberos Vault Plugin mantenido por Stratio, que permite la interacción con un KDC y el gestor de secretos Transit para cifrado transparente.

Se soportan dos formas de persistencia centralizada de secretos: Secrets de Kubernetes y el KV de secretos de Vault.

Secretos de Kubernetes

Los secretos se representan con un objeto de la API de Kubernetes y se persisten en etcd¹.

En Stratio Augmented Data Fabric, el API Server cifra todos los secretos antes de almacenarlos en etcd con una clave configurada en los nodos de control-plane.

Estos son utilizados, por ejemplo, para los tokens de las Service Accounts.

Para crear un Secret se debe indicar su tipo, pudiendo ser opaco (genérico), token de SA, credenciales de Docker, autenticación basic o SSH, TLS (certificados), o token de bootstrap (utilizados en la inicialización de los nodos). Los campos se deben codificar en base64².

La creación se realizará con una petición al API Server con una forma implícita usando Kubectl, o bien con la definición del Secret que necesitará nuestra aplicación.

Lacreación de un Secret requiere indicar el secreto que será almacenado en el objeto. Esta opción no genera los secretos en sí, solo los almacena.

El consumo de los Secrets desde un Pod puede realizarse de dos formas: como ficheros o como variables de entorno.

Dado que los Secrets son objetos de la API de Kubernetes, el acceso se autoriza utilizando su RBAC³

Secretos de Vault

En Stratio KEOS, y dado que la seguridad de los Secrets, para ciertos casos de uso es cuestionable, se brinda la opción de utilizar el KV de secretos de Vault. Idealmente, todas las aplicaciones deberían utilizar este método, pero su consumo requiere hacer login en Vault.

Para facilitar la generación de secretos se utilizará secrets-operator, que va a controlar dos objetos: Secret Bundle (crear el certificado o usuario/password en Vault) y SecretsIdentity (para decir a que service account va asociado ese secret bundle y que permisos tiene de acceso a ellos)

• En el SecretsBundle se define el secreto a crear, indicando su tipo (certificado, contraseña o keytab) y los detalles para cada caso, como el commonName y altNames para certificados, un nombre y usuario para contraseñas o el principal para los keytabs.
• El controlador se encargará de crear estos secretos y persistirlos en el KV Vault, en rutas conocidas. Para la generación de certificados se utilizará la PKI Engine de Vault configurada para el tenant, y para los keytabs un Kerberos Vault Plugin mantenido por Stratio.

Es una capa más de secretos encriptados en Vault que tiene una seguridad extra, ya que no cualquiera puede acceder a Vault y donde se guardan este tipo de secretos

Actualmente,el acceso a Vault se realiza usando el token de la Service Account del Pod y está basado en el método de autenticación “Kubernetes”.

En este caso, el controlador creará las políticas y roles necesarios en Vault para que dicha Service Account pueda consumirlos.

Stratio KEOS utiliza como backend de Vault un cluster propio de etcd (key-value fiable, fuertemente consistente y distribuido usado como backend de Kubernetes) desplegado como StatefulSet

Para el despliegue de Vault se utiliza el operador banks-vault, que aporta gran facilidad en la instalación, actualizaciones y manejo del ciclo de vida, así como la funcionalidad de desellado automático de Vault.

En Stratio KEOS, el consumo de secretos puede realizarlo la propia aplicación con su Service Account o bien delegarlo al Agent Sidecar Injector, un webhook mutante de Vault que renderiza secretos en los Pods según las anotaciones de éste. Para ello, añade un contenedor sidecar al Pod y utiliza su Service Account para el acceso a Vault.

1 Etcd es un almacén de valor clave coherente y de alta disponibilidad 
que se utiliza como almacén de respaldo de Kubernetes para todos los datos del clúster.
2 Base64. es un sistema de numeración posicional que usa 64 como base. 
Es la mayor potencia que puede ser representada usando únicamente los caracteres imprimibles de ASCII. 
Esto ha propiciado su uso para codificación de correos electrónicos, 
PGP y otras aplicaciones. 
3 Role Based Acces Control. Este modelo de seguridad permite asignar funciones y autorizaciones en 
la infraestructura informática de una organización. El término “basado en roles” es clave, en este modelo, 
el administrador del sistema asigna un nivel y una categoría de seguridad a cada usuario y objeto en 
dependencia del rol que cumple. El sistema operativo enlaza automáticamente los dos niveles y luego concede o deniega el
acceso.

LDAP y Kerberos

Stratio KEOS despliega un LDAP como proveedor de identidades de la plataforma, permitiendo también utilizar uno externo. Este LDAP se configurará en el SIS para SSO y en Stratio GoSec para la sincronización de identidades.

También se despliega un Kerberos con el LDAP (interno o externo) como backend. La autenticación con Kerberos se utiliza para workspaces de entornos analíticos y HDFS.

Para el caso de requerir el consumo del servicio de Kerberos desde fuera del cluster, para soportar herramientas externas para gestión del LDAP, se da la opción de exponerlo hacia el exterior a través de servicios en L4 como LDAP.

Si los nodos se aprovisionan con Kerberos configurado, se permitirá el uso de servicios externos kerberizados y, en caso de proveer un keytab de administración, se configurará el plugin de Kerberos de Vault para la creación dinámica de keytabs.

Políticas de Seguridad

SELinux

Stratio KEOS puede desplegarse con las políticas deSELinux activadas en modo "enforcing", si bien por defecto se despliega con dichas políticas en modo "permissive".

SELinux permite evitar cambios indeseados en el sistema operativo, estableciendo políticas de seguridad que restringen el acceso y modificación de ficheros esenciales del sistema o de puertos privilegiados.

Algunos programas necesitan acceder a estos ficheros, pero existen unas políticas predefinidas que se pueden listar con sepolicy -l y que cubren las necesidades del producto. Pueden presentarse problemas si estas políticas predeterminadas han sido eliminadas o modificadas.

Para consultar los mensajes relativos a bloqueos o restricciones emitidas por SELinux, puedes usar el comando: journalctl -t setroubleshoot.

Kyverno

El motor de políticas de seguridad utilizado en Stratio KEOS es Kyverno, quien gestiona políticas con objetos de la API de Kubernetes (Policy y ClusterPolicy).

Las Policies de Kyverno son colecciones lógicas de reglas (una política con dos reglas es igual a dos políticas separadas, una con cada una de esas reglas), que pueden ser de mutación, validación o generación.

Las reglas de validación pueden tener una acción de “enforce” (bloquea) o “audit” (solo audita), este último puede utilizarse para obtener un reporte de recursos que no cumplen con las políticas.

Cabe destacar la posibilidad de crear variables con llamadas al API Server en la política, que se pueden utilizar posteriormente en las reglas.

Kyverno pone a disposición de cualquier usuario, políticas por defecto y altamente restrictivas de acuerdo a los Pod Security Standards de Kubernetes.

Para exportar los informes generados con los incumplimientos a las políticas en modo auditoría, se puede utilizar el policy-reporter (no desplegado en Stratio KEOS). Con este módulo, la exportación puede realizarse a Prometheus y permitirá integrarse con Elasticsearch y Slack, entre otros.

La instalación de Stratio KEOS despliega las siguientes políticas de seguridad de Stratio (no se crean las políticas que trae Kyverno por defecto):

• Permitir solo una IngressClass por defecto.
• Prohibir guiones en nombres de tenants (evita confusión de pertenencia en los Namespaces).
• Prohibir servicios de tipo NodePort.
• Prohibir el uso de NodeName en el despliegue de los Pods.
• Generar una NetworkPolicy en los nuevos Namespaces permitiendo el tráfico saliente (cerrado por defecto). Esta política de red puede eliminarse si se desea (no volverá a crearse).

1 Sssd (System Security Services Daemon). System Security Services Daemon es un software 
desarrollado originalmente para el sistema
operativo Linux que proporciona un conjunto de demonios para 
administrar el acceso a servicios de directorio remoto y mecanismos de autenticación.

Políticas de Tenant

Posteriormente, tras la creación de un objeto Tenant y siempre y cuando su anotación stratio.tenant.kubernetes.io/disable-sec-policie esté configurada con el valor "false" (valor por defecto), se crearán automáticamente una serie de objetos ClusterPolicy con el objetivo de bloquear ciertas configuraciones en cargas de trabajo y otros objetos de un tenant que se consideran inseguras porque podrían utilizarse para comprometer la seguridad del cluster.

Por cada tenant existirá una política de seguridad de las especificadas a continuación (cuyo nombre tendrá el prefijo "tenant-<nombre_tenant>-").

Políticas de Namespace

Para la instalación de los aplicativos Stratio Rocket o Stratio Intelligence será necesario realizar una preconfiguración del entorno y de los Namespaces para su correcto funcionamiento, la cual incluye la creación de tres políticas de seguridad (Policy) dentro del Namespace objetivo, cuyo propósito se especifica a continuación:

• disallow-serviceaccounttoken-mapping

Política de tipo validación que intercepta y rechaza cualquier petición de creación/modificación de una carga de trabajo dentro del Namespace correspondiente, que configure en su definición del pod una variable de entorno o volumen cuyo valor provenga de un objeto Secret de tipo kubernetes.io/service-account-token con el objetivo de que un usuario no confiable pueda mapear en un nuevo pod un Service Account Token de otro usuario.

• restrict-(intelligence|rocket)-images

Política de tipo validación que intercepta y rechaza cualquier petición de creación/modificación de una carga de trabajo dentro del Namespace correspondiente, que utilice en cualquiera de sus contenedores una imagen diferente de las estrictamente necesarias por el aplicativo en concreto con el objetivo de reducir la superficie de ataque por un usuario malicioso desde un pod no confiable.

• restrict-serviceaccount-use

Política de tipo validación que intercepta y rechaza cualquier petición de creación/modificación/eliminación de un pod dentro del Namespace correspondiente, cuya Service Account sea diferente de la del usuario que envía dicha petición con el objetivo de bloquear cualquier intento de impersonación o denegación de servicio sobre otro pod por parte de un usuario no confiable.