GLPI,es una herramienta web en software libre que ofrece una gestión integral del inventario informático de una empresa además de incluir un sistema de gestión de incidencias (ticketing / helpdesk). La herramienta está desarrollada para entornos Apache-PHP-MySQL, por lo que puede ser instalada tanto en servidores windows como linux y su fácil instalación y manejo permite gestionar todo el soporte y mantenimiento de una empresa de una manera rápida y sencilla, por lo que el despliegue y la puesta en marcha son bastante reducidos. Si se dispone de un directorio LDAP, se puede usar y directamente se tendrá de alta en el sistema a todo el personal. Este doble papel de gestor de inventario (equipos, servidores, periféricos, licencias de software, topología de red, reserva de recursos compartidos, etc) y helpdesk para el seguimiento de intervenciones, permite a los administradores, y al personal de soporte, vincular las intervenciones realizadas a Usuarios y a equipos, generándose así un historial completo del mantenimiento realizado
Compatible den ITIL
El modulo de asistencia y servicio de GLPI cumple con los estándares específicos del ITIL v2, el guía de mejores practicas mas ampliamente aceptada en el mundo para estructuras de trabajos para software de administración de servicios. Combina categorización, escalabilidad, acuerdos de nivel de servicio, impacto, urgencias, calculación de prioridad, estandarización del estatus, solicitud de validaciones en varios niveles y la implementación de flujos de trabajos automáticos basados en la política de la organización.
Visualiza el ciclo de vida de un incidente o solicitud de servicio (asignación, planificación, validación, tareas, seguimientos, soluciones, etc.)
Crea o actualiza tickets vía correo electrónico IMAP / POP.
Datos valiosos de tus activos: Costo total de propiedad, monitoreo de fallas, etc.
Plantillas de tickets predefinidos para incidentes, solicitud de servicio, soluciones, y tareas.
Manejo de disponibilidad y horas de atención.
Base de conocimiento enlazado a tickets que pueden automáticamente escalar problemas, cambios o proyectos.
Generador de formatos personalizados.
Flujo de trabajo automático basado en reglas complejas de la organización.
Manejo de acuerdos de niveles de servicio (SLA), objetivo de nivel de servicio (SLT) y acuerdo de nivel operacional (OLA).
Encuesta de satisfacción luego de cerrado el ticket.
Problemas
Creación de problema desde diversas fuentes: formularios, incidentes, cambios y parque de bienes. Análisis del impacto de problemas, evaluación de síntomas y encontrar sus causas. Seguimiento del progreso hasta hallar una valida solución. Alimentación de la base de conocimiento con información valiosa de errores. Trazabilidad de costos para planificación de calendarios y materiales.
Cambios
Crear cambios por incidentes, solicitudes o problemas. Análisis, planeación, soluciones. Enlaza cambios con la base de conocimiento. Enlaza cambios a objetos en el inventario. Manejo de gastos.
Instalación en Linux Ubuntu 18.04.3 LTS
Instalación_GLPI.sh
####Programa Install GLPI ##
#!/bin/sh
echo"Inicia programa de instalación GLPI"
sudo apt update -y
sudo apt install apache2 -y
sudo apt install mysql-server -y
echo"Ejecuta Query de MySQL"
sudo mysql
SELECT user,authentication_string,plugin,host FROM mysql.user;
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';
El Protocolo simple de administración de redes (SNMP) es un protocolo
de capa de aplicación definido por la Junta de arquitectura de Internet
(IAB) en RFC1157 para intercambiar información de administración entre
dispositivos de red. Forma parte del conjunto de protocolos Protocolo de
control de transmisión/Protocolo de Internet (TCP/IP).
SNMP es uno de los protocolos ampliamente aceptados para administrar y
monitorizar elementos de red. La mayoría de los elementos de red de
nivel profesional vienen con un agente SNMP incluido. Estos agentes
deben estar habilitados y configurados para comunicarse con el sistema
de administración de red (NMS).
Comandos básicos de SNMP
La simplicidad en el intercambio de información ha convertido al SNMP
en un protocolo ampliamente aceptado. La razón principal es un conjunto
conciso de comandos, que se enumeran a continuación:
GET: La operación GET es una solicitud enviada por el
administrador al dispositivo administrado. Se realiza para recuperar uno
o más valores del dispositivo administrado.
GET NEXT: Esta operación es parecida a la GET. La diferencia
significativa es que la operación GET NEXT recupera el valor del
siguiente OID en el árbol MIB.
GET BULK: La operación GETBULK se utiliza para recuperar datos voluminosos de una tabla MIB grande.
SET: Los administradores utilizan esta operación para modificar o asignar el valor del dispositivo administrado.
TRAPS: A diferencia de los comandos anteriores que se inician
desde el administrador SNMP, los agentes inician TRAPS. Es una señal al
administrador SNMP por parte del agente sobre la repetición de un
evento.
INFORM: Este comando es similar al TRAP iniciado por el agente,
además, INFORM incluye la confirmación del administrador SNMP al recibir
el mensaje.
RESPONSE: Es el comando utilizado para transportar los valores o
la señal de las acciones dirigidas por el administrador de SNMP.
Administrador SNMP:
Un administrador o sistema de administración es una entidad separada
responsable de comunicarse con los dispositivos de red implementados por
el agente SNMP. Normalmente es un equipo que se utiliza para ejecutar
uno o más sistemas de administración de red.
Funciones clave del administrador SNMP
Agentes de consultas
Obtiene respuestas de agentes
Establece variables en agentes
Reconoce eventos asincrónicos de agentes
Dispositivos administrados:
Un dispositivo administrado o el elemento de red es una parte de la
red que requiere algún tipo de monitorización y administración, por
ejemplo, enrutadores, conmutadores, servidores, estaciones de trabajo,
impresoras, UPS, etc.
Agente SNMP:
El agente es un programa que está empaquetado dentro del elemento de
red. La habilitación del agente le permite recopilar la base de datos de
información de administración del dispositivo localmente y la pone a
disposición del administrador SNMP, cuando se le solicita. Estos agentes
pueden ser estándar (por ejemplo, Net-SNMP) o específicos de un
proveedor (por ejemplo, HP Insight Agent)
Funciones clave del agente SNMP
Recopila información de administración sobre su entorno local
Almacena y recupera información de gestión según se define en la MIB.
Señala un evento al administrador.
Actúa como proxy para algunos nodos de red administrables que no son SNMP.
Base de datos de información de administración o Base de información de administración (MIB)
Cada agente SNMP mantiene una base de datos de información que
describe los parámetros del dispositivo administrado. El administrador
SNMP usa esta base de datos para solicitar al agente información
específica y traduce aún más la información según sea necesario para el
Sistema de administración de red (NMS). Esta base de datos comúnmente
compartida entre el Agente y el Administrador se denomina Base de
información de administración (MIB).
Por lo general, estas MIB contienen un conjunto estándar de valores
estadísticos y de control definidos para nodos de hardware de una red.
SNMP también permite la extensión de estos valores estándar con valores
específicos para un agente en particular mediante el uso de MIB
privadas.
En resumen, los archivos MIB son el conjunto de preguntas que un
administrador SNMP puede hacerle al agente. El agente recopila estos
datos localmente y los almacena, según se define en la MIB. Por lo
tanto, el administrador de SNMP debe conocer estas preguntas estándar y
privadas para cada tipo de agente.
Como saben tengo la fortuna de tener múltiples sistemas operativos en casa (Ubuntu, Kali, Mac Os, Windows, Windows, Server, CentOs, RedHat, etc. ) todo por el maravilloso mundo donde laboro. hace ya un tiempo Microsoft me invito a evaluar el nuevo Windows Server 2019 y compartí mi punto de vista hace aproximadamente 4 meses. ahora lo uso como laboratorio para mis pruebas funcionales con soluciones con las cuales laboro, aprovechando que aun tengo el periodo de días de evaluación tome la decisión de compartir con ustedes como agregar un nuevo disco duro en el escenario que sea administradores Junior de sistemas operativos windows de la gama de servidores, en realidad es muy sencillo. comparto un video de ejemplo.
En algunas ocasiones instalamos tantos repos que en ocasiones tenemos duplicados y no nos damos cuenta. en su casa en mi equipo de escritorio hoy se presento el siguiente mensaje al intentar buscar actualizaciones para mi sistema operativo GNU/Linux el cual me indica "tengo duplicidad en mis repositorios de actualizaciones" por lo cual retirar la duplicidad es relativamente fácil. pensando en que posiblemente sea la primera ocación que tienes este tipo de mensajes y te quedaste con cara de WTF! te comparto como puedes retirar facil y rapido duplicidad en los repo list de GNU/Linux.
este es el mensaje en mi terminal que me indica que tengo Packages configurado varias veces en rutas en especifico del sistema operativo.
oposada@gnu:~$ sudo apt-get update [sudo] contraseña para oposada: Obj:1 http://repo.steampowered.com/steam precise InRelease Obj:2 http://packages.microsoft.com/repos/vscode stable InRelease Obj:3 http://repository.spotify.com stable InRelease Obj:4 http://archive.ubuntu.com/ubuntu disco InRelease Obj:5 http://archive.canonical.com/ubuntu disco InRelease Obj:6 http://apt.postgresql.org/pub/repos/apt disco-pgdg InRelease Obj:7 https://download.docker.com/linux/ubuntu disco InRelease Obj:8 http://archive.ubuntu.com/ubuntu disco-updates InRelease Obj:9 http://archive.ubuntu.com/ubuntu disco-backports InRelease Obj:10 http://archive.ubuntu.com/ubuntu disco-security InRelease Leyendo lista de paquetes... Hecho W: El objetivo Packages (partner/binary-amd64/Packages) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo Packages (partner/binary-i386/Packages) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo Packages (partner/binary-all/Packages) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo Translations (partner/i18n/Translation-es_MX) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo Translations (partner/i18n/Translation-es) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo Translations (partner/i18n/Translation-en) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo DEP-11 (partner/dep11/Components-amd64.yml) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo DEP-11 (partner/dep11/Components-all.yml) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo DEP-11-icons-small (partner/dep11/icons-48x48.tar) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo DEP-11-icons (partner/dep11/icons-64x64.tar) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo CNF (partner/cnf/Commands-amd64) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo CNF (partner/cnf/Commands-all) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 N: Omitiendo el uso del fichero configurado «main/binary-i386/Packages» ya que el repositorio «http://apt.postgresql.org/pub/repos/apt disco-pgdg InRelease» no admite la arquitectura «i386» W: El objetivo Packages (partner/binary-amd64/Packages) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo Packages (partner/binary-i386/Packages) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo Packages (partner/binary-all/Packages) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo Translations (partner/i18n/Translation-es_MX) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo Translations (partner/i18n/Translation-es) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo Translations (partner/i18n/Translation-en) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo DEP-11 (partner/dep11/Components-amd64.yml) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo DEP-11 (partner/dep11/Components-all.yml) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo DEP-11-icons-small (partner/dep11/icons-48x48.tar) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo DEP-11-icons (partner/dep11/icons-64x64.tar) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo CNF (partner/cnf/Commands-amd64) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 W: El objetivo CNF (partner/cnf/Commands-all) está configurado varias veces en /etc/apt/sources.list:43 y /etc/apt/sources.list.d/disco-partner.list:4 Solución Ve a actualizar (si tienes instalado el entorno grafico ) presiona "Configuración"
Ve ala pestaña de "otros software" retira los duplicados y listo.
Netdata es un monitoreo distribuido, en tiempo real, de rendimiento y salud para sistemas y aplicaciones. Es un agente de monitoreo altamente optimizado que instala en todos sus sistemas y contenedores.
Netdata proporciona información incomparable, en tiempo real, de todo lo que sucede en los sistemas que ejecuta (incluidos servidores web, bases de datos, aplicaciones), utilizando paneles web altamente interactivos. Puede ejecutarse de forma autónoma, sin componentes de terceros, o puede integrarse a las cadenas de herramientas de monitoreo existentes (Prometheus, Graphite, OpenTSDB, Kafka, Grafana, etc.).
Netdata es rápido y eficiente, diseñado para ejecutarse permanentemente en todos los sistemas (servidores físicos y virtuales, contenedores, dispositivos IoT), sin interrumpir su función principal.
Netdata es un software gratuito de código abierto y actualmente se ejecuta en Linux, FreeBSD y MacOS.
Sus datos están seguros con Netdata¶
Netdata recopila datos sin procesar de muchas fuentes. Para cada fuente, Netdata utiliza un complemento que se conecta a la fuente (o lee los archivos relativos producidos por la fuente), recibe datos sin procesar y los procesa para calcular las métricas que se muestran en los paneles de Netdata.
Incluso si los complementos de Netdata se conectan a su servidor de base de datos o leen el archivo de registro de la aplicación para recopilar datos sin procesar, el producto de este proceso de recopilación de datos es siempre una serie de metadatos de gráficos y valores métricos (datos resumidos para la visualización del tablero). Todos los complementos de Netdata (internos al demonio de Netdata y externos escritos en cualquier lenguaje de computadora), convierten los datos sin procesar recopilados en métricas, y solo estas métricas se almacenan en bases de datos de Netdata, se envían a servidores de Netdata ascendentes o se archivan para series de tiempo de backend bases de datos
Los datos brutos recopilados por Netdata no dejan el host donde se recopilan. Los únicos datos que expone Netdata son los metadatos del gráfico y los valores métricos.
Esto significa que Netdata se puede usar de forma segura en entornos que requieren el más alto nivel de aislamiento de datos (como PCI Nivel 1).
Sus sistemas están seguros con Netdata¶
Estamos muy orgullosos de que el demonio Netdata se ejecute como un usuario normal del sistema, sin ningún privilegio especial. Este es un gran logro para un sistema de monitoreo que recopila todo tipo de métricas de sistemas y aplicaciones.
Sin embargo, hay algunos casos en los que los datos de origen sin procesar solo están expuestos a procesos con privilegios escalados. Para admitir estos casos, Netdata intenta minimizar y aislar completamente el código que se ejecuta con privilegios escalados.
Por lo tanto, los complementos de Netdata, incluso aquellos que se ejecutan con capacidades o privilegios escalados, realizan un trabajo de recopilación de datos codificado. No aceptan comandos de Netdata. La comunicación es estrictamente unidireccional: desde el complemento hacia el demonio Netdata. Los datos de la aplicación original recopilados por cada complemento no abandonan el proceso en el que se recopilan, no se guardan y no se transfieren al demonio Netdata. La comunicación de los complementos al demonio Netdata incluye solo metadatos de gráficos y valores métricos procesados.
Netdata esclava las métricas de transmisión a los servidores de Netdata, use exactamente el mismo protocolo que usan los complementos locales. Los datos sin procesar recopilados por los complementos de los servidores esclavos Netdata nunca abandonan el host donde se recopilan. Los únicos datos que aparecen en el cable son metadatos de gráficos y valores métricos. Esta comunicación también es unidireccional: los servidores Netdata esclavos nunca aceptan comandos de servidores Netdata maestros.
Netdata es de solo lectura¶
Los paneles de Netdata son de solo lectura. Los usuarios del panel pueden ver y examinar las métricas recopiladas por Netdata, pero no pueden indicar a Netdata que haga algo más que presentar las métricas ya recopiladas.
Los paneles de Netdata no exponen información confidencial. Los datos comerciales de cualquier tipo, la versión del kernel, la versión O / S, las versiones de la aplicación, las IP del host, etc., no se almacenan y Netdata no los expone en sus paneles. Autenticación de espectadores de Netdata¶
Netdata es un sistema de monitoreo. Debe estar protegido, de la misma manera que proteges todas tus aplicaciones de administración. Suponemos que Netdata se instalará de forma privada, solo para sus ojos. Por qué se debe proteger Netdata¶
Los espectadores podrán obtener información sobre el sistema que Netdata está ejecutando. Esta información es todo lo que proporciona el tablero. El panel de control incluye una lista de los servicios que ejecuta cada sistema (las leyendas de los gráficos en la sección Servicios de Systemd), las aplicaciones que se ejecutan (las leyendas de los gráficos en la sección de Aplicaciones), los discos del sistema y sus nombres, el usuario cuentas del sistema que están ejecutando procesos (la sección Usuarios y grupos de usuarios del tablero), las interfaces de red y sus nombres (no las IP) e información detallada sobre el rendimiento del sistema y sus aplicaciones.
Esta información no es confidencial (lo que significa que no son los datos de su empresa), pero es importante para los posibles atacantes. Les dará pistas sobre qué verificar, qué probar y, en el caso de DDoS contra sus aplicaciones, sabrán si lo están haciendo bien o no.
Además, los espectadores podrían usar Netdata para estresar sus servidores. Aunque el demonio Netdata se ejecuta sin privilegios, con la prioridad de proceso mínima (prioridad de programación inactiva - menor que 19) y ajusta su puntaje OutOfMemory (OOM) a 1000 (para que el núcleo lo mate primero si el sistema se muere de hambre por memoria), se puede aplicar cierta presión en sus sistemas si alguien intenta un DDoS contra Netdata. Proteger Netdata de internet¶
Netdata es una aplicación distribuida. Lo más probable es que tenga muchas instalaciones de la misma. Como se distribuye y se espera que salte de un servidor a otro, hay muy poca usabilidad para agregar autenticación local en cada Netdata.
Hasta que agreguemos un método de autenticación distribuida a Netdata, tiene las siguientes opciones: Exponga Netdata solo en una LAN privada¶
Si su organización tiene una LAN de administración y administración privada, puede vincular Netdata en esta interfaz de red en todos sus servidores. Esto se hace en Netdata.conf con esta configuración:
[web]
bind to = 10.1.1.1:19999 localhost:19999
Puede vincular Netdata a múltiples IP y puertos. Si usa nombres de host, Netdata los resolverá y usará todas las IP (en el ejemplo anterior, localhost generalmente se resuelve en 127.0.0.1 y :: 1).
Esta es la mejor y la forma sugerida de proteger Netdata. Sus sistemas deben tener una LAN de administración y administración privada, de modo que todas las tareas de administración se realicen sin ninguna posibilidad de que estén expuestas en Internet.
Para instalaciones basadas en la nube, si su proveedor de la nube no proporciona una LAN privada (o si utiliza varios proveedores), puede crear una LAN virtual de administración y administración con herramientas como tincd o gvpe. Estas herramientas crean una VPN de malla que permite que todos los servidores se comuniquen de forma segura y privada. Sus estaciones de administración se unen a esta VPN de malla para obtener acceso a las tareas de administración y administración en todos sus servidores en la nube.
Para gvpe, hemos desarrollado una herramienta de aprovisionamiento simple que puede encontrar útil (incluye binarios de gvpe compilados estáticamente para Linux y FreeBSD, y también un script para compilar gvpe en su Mac). Usamos esto para crear una LAN de administración y administración para todos los sitios de demostración de Netdata (distribuidos por todo Internet utilizando múltiples proveedores de alojamiento).
En Netdata v1.9 + también hay soporte para la lista de acceso, como este:
[web] enlazar a = * permitir conexiones desde = localhost 10. * 192.168. *
Use un servidor web de autenticación en modo proxy¶
Use un servidor web para proporcionar autenticación frente a todos sus servidores Netdata. Por lo tanto, accederá a todos sus Netdata con URL como http: // {HOST} / netdata / {NETDATA_HOSTNAME} / y la autenticación se compartirá entre todos ellos (iniciará sesión una vez para todos sus servidores). Se proporcionan instrucciones sobre cómo configurar la configuración del proxy para que Netdata se ejecute detrás de nginx, Apache, lighthttpd y Caddy.
Para utilizar este método, debe proteger con firewall todos sus servidores Netdata, de modo que solo la IP del servidor web pueda acceder directamente a Netdata. Para hacer esto, ejecute esto en cada uno de sus servidores (o use su administrador de firewall):
comandos para permitir el acceso directo a Netdata desde un servidor proxy web
Lo anterior evitará que cualquier persona, excepto su servidor web, acceda a un panel de Netdata que se ejecuta en el host.
Para Netdata v1.9 + también puede usar netdata.conf:
[web] permitir conexiones desde = localhost 1.2.3.4
Por supuesto, puede agregar más IP.
Para Netdata anterior a v1.9, si desea permitir múltiples IP, use esto:
# lista de direcciones IP separadas por espacios para permitir el acceso a Netdata NETDATA_ALLOWED = "1.2.3.4 5.6.7.8 9.10.11.12" NETDATA_PORT = 19999
# crear una nueva cadena de filtrado || o vaciar uno existente llamado netdata iptables -t filtro -N netdata 2> / dev / null || iptables -t filtro -F netdata para x en $ {NETDATA_ALLOWED} hacer # permitir esta IP iptables -t filter -A netdata -s $ {x} -j ACEPTAR hecho
# descartar todas las demás IP iptables -t filter -A netdata -j DROP
# eliminar el gancho de la cadena de entrada (si existe) iptables -t filter -D INPUT -p tcp --dport $ {NETDATA_PORT} -m conntrack --ctstate NEW -j netdata 2> / dev / null
# agregue el gancho de la cadena de entrada (nuevamente) # para enviar todas las nuevas conexiones de Netdata a nuestra cadena de filtrado iptables -t filtro -I INPUT -p tcp --dport $ {NETDATA_PORT} -m conntrack --ctstate NUEVO -j netdata
script para permitir el acceso a Netdata solo desde varios hosts
Puede ejecutar lo anterior cualquier cantidad de veces. Cada vez que se ejecuta, actualiza la lista de hosts permitidos. Otros metodos¶
Por supuesto, hay muchos más métodos que podría usar para proteger Netdata:
enlace Netdata a localhost y use ssh -L 19998: 127.0.0.1: 19999 remote.netdata.ip para reenviar las conexiones del puerto local 19998 al puerto remoto 19999. De esta manera puede enviar ssh a un servidor Netdata y luego usar http: //127.0 .0.1: 19998 / en su computadora para acceder al panel de control remoto de Netdata.
Si siempre está bajo una IP estática, puede usar la secuencia de comandos anterior para permitir el acceso directo a sus servidores Netdata sin autenticación, desde todas sus IP estáticas.
instale todos sus Netdata en modo de recopilador de datos sin cabeza, reenviando todas las métricas en tiempo real a un servidor Netdata maestro, que estará protegido con autenticación utilizando un servidor nginx que se ejecuta localmente en el servidor Netdata maestro. Esto requiere más recursos (necesitará un servidor Netdata maestro más grande), pero no requiere ningún cambio de firewall, ya que todos los servidores Netdata esclavos no escucharán las conexiones entrantes.
Estadísticas anónimas¶ Registro o cómo no enviar ninguna información a un servidor de terceros¶
La configuración predeterminada utiliza un registro público en register.my-netdata.io (más información sobre el registro aquí: mynetdata-menu-item). Tenga en cuenta que si utiliza ese registro público, envía la siguiente información a un servidor de terceros:
La url donde abre la interfaz de usuario web en el navegador (a través de http request referer) Los nombres de host de los servidores de Netdata
Si envía esta información al Netd central
un registro viola sus políticas de seguridad, puede configurar Netdat para ejecutar su propio registro. Inhabilitar estadísticas anónimas¶
A partir de v1.12, Netdata también recopila estadísticas anónimas sobre ciertos eventos para:
Garantía de calidad, para ayudarnos a comprender si Netdata se comporta como se espera y ayudarnos a identificar problemas recurrentes para ciertas distribuciones o entornos.
Estadísticas de uso, para ayudarnos a centrarnos en las partes de Netdata que más se usan, o ayudarnos a identificar la medida en que nuestras decisiones de desarrollo influyen en la comunidad.
Para optar por no enviar estadísticas anónimas, puede crear un archivo llamado .opt-out-from-anonymous-statistics en el directorio de configuración del usuario (generalmente / etc / netdata).
Netdata config files may contain sensitive information, so group netdata is allowed to read them.
/usr/libexec/netdata
user root group root
executable by anyone dirs 0755 files 0644 or 0755
executes
Netdata plugins permissions depend on the file - not all of them should have the executable flag. there are a few plugins that run with escalated privileges (Linux capabilities or setuid) - these plugins should be executable only by group netdata.
/usr/share/netdata
user root group netdata
readable by anyone dirs 0755 files 0644
reads and sends over the network
Netdata web static files these
files are sent over the network to anyone that has access to the Netdata
web server. Netdata checks the ownership of these files (using settings
at the [web] section of netdata.conf) and
refuses to serve them if they are not properly owned. Symbolic links are
not supported. Netdata also refuses to serve URLs with .. in their name.
Netdata permanent database files Netdata stores here the registry data, health alarm log db, etc.
/var/log/netdata
user netdata group root
dirs 0755 files 0644
writes, creates
Netdata log files all the Netdata
applications, logs their errors or other informational messages to files
in this directory. These files should be log rotated.
Microsoft Azuere y los contenedores tomaron mucha fuerza en los ultimos años desde sus inicios, es normal en estos tiempos hablar y escuchar de la computación en la nube con tecnologías como Azure, Google Cloud, AWS, contenedores, servicios y micro servicios.
Como amantes de las tecnologías de la información es nuestra obligación estar al día en aspectos relacionados a los avances tecnológicos y obviamente la nube es uno de ello. en mi experiencia no podemos hablar de arquitectura de nube sin tener en consideración y conocer de los siguientes conceptos claves que te ayudarán a entender o darte mejor idea de que es lo que rodea una arquitectura de micro servicios basado en contenedores con Kubernetes y el servicio de Microsoft Azure.
La arquitectura de referencia muestra una aplicación de microservicios implementada en Azure Kubernetes Service (AKS). Describe una configuración básica de AKS que puede ser el punto de partida para la mayoría de las implementaciones.
Azure Kubernetes Service (AKS). AKS es un servicio de Azure que implementa un clúster de Kubernetes administrado.
Clúster de Kubernetes. AKS es responsable de implementar el clúster de Kubernetes y de administrar los maestros de Kubernetes. Solo debe administrar los nodos de agente lo cual es genial si no cuentas con experiencia en la implementación de Docker & Kubernetes, agiliza mucho el tiempo de implementación y pasas directamente a tiempo de administración y menejo de los nodos.
Red virtual. "De forma predeterminada", AKS crea una red virtual para implementar en ella los nodos de agente. Para escenarios más avanzados, puede crear la red virtual en primer lugar, lo que le permite controlar elementos como la configuración de las subRedes, la conectividad local y el direccionamiento IP.
Entrada. Una entrada expone rutas HTTP(S) a servicios dentro del clúster.
Azure Load Balancer. Cuando se implementa el controlador de entrada NGINX, se crea un equilibrador de carga de Azure. El equilibrador de carga enruta el tráfico de internet a la entrada.
Almacenes de datos externos. Los microservicios son normalmente sin estado y escriben el estado en almacenes de datos externos, como Azure SQL Database o Cosmos DB.
Azure Active Directory. AKS usa una identidad de Azure Active Directory (Azure AD) para crear y administrar otros recursos de Azure, como los equilibradores de carga de Azure. Azure AD también se recomienda para la autenticación de usuario en aplicaciones cliente.
Azure Container Registry. Utilice Container Registry para almacenar imágenes de Docker privadas, que se implementan en el clúster. AKS se puede autenticar con Container Registry con su identidad de Azure AD. Tenga en cuenta que AKS no requiere Azure Container Registry. Puede usar otros registros de contenedor, como Docker Hub.
Azure Pipelines. Pipelines es parte de Azure DevOps Services y ejecuta compilaciones, pruebas e implementaciones automatizadas. También puede usar soluciones de CI/CD de terceros como Jenkins.
Helm. Helm es un administrador de paquetes para Kubernetes: una manera de agrupar objetos de Kubernetes en una sola unidad que se puede publicar, implementar, versionar y actualizar.
Azure Monitor. Azure Monitor recopila y almacena métricas y registros, incluidas las métricas de plataforma para los servicios de Azure de la solución y los datos de telemetría de la aplicación. Use estos datos para supervisar la aplicación, configurar alertas y paneles y realizar el análisis de causa principal de los errores. Azure Monitor se integra con AKS para recopilar métricas de controladores, nodos y contenedores, así como los registros de contenedor y los registros del nodo maestro.
Consideraciones de diseño Esta arquitectura de referencia se centra en las arquitecturas de microservicios, aunque muchos de los procedimientos recomendados se aplicarán a otras cargas de trabajo que se ejecutan en AKS.
Microservicios
El objeto de Kubernetes Service es una manera natural para modelar microservicios en Kubernetes. Un microservicio es una unidad de código de acoplamiento flexible que se puede implementar de forma independiente. Los microservicios normalmente se comunican mediante API bien definidas y son detectables por algún tipo de detección de servicios. El objeto de Kubernetes Service proporciona un conjunto de funcionalidades que coinciden con estos requisitos:
Dirección IP. El objeto del servicio proporciona una dirección IP interna estática para un grupo de pods (conjunto de réplicas). A medida que los pods se crean o se mueven, el servicio siempre está accesible en esta dirección IP interna.
Equilibrio de carga. La carga del tráfico enviado a la dirección IP del servicio se equilibra en los pods.
Detección de servicios. El servicio DNS de Kubernetes asigna entradas DNS internas a los servicios. Esto significa que la puerta de enlace de API puede llamar a un servicio de back-end con el nombre DNS. Se puede usar el mismo mecanismo para la comunicación de servicio a servicio. Las entradas DNS están organizadas por espacio de nombres, por lo que si los espacios de nombres se corresponden con contextos limitados, el nombre DNS de un servicio se asignará de forma natural al dominio de aplicación. El diagrama siguiente muestra la relación conceptual entre servicios y pods. La asignación real a los puertos y las direcciones IP del punto de conexión se realiza mediante kube-proxy, el proxy de red de Kubernetes.
API Gateway
Una puerta de enlace de API es una puerta de enlace que se encuentra entre los clientes externos y los microservicios. Actúa como un proxy inverso, enrutando las solicitudes de los clientes a los microservicios. También puede realizar diversas tareas transversales como la autenticación, la terminación SSL y la limitación de velocidad.
La funcionalidad proporcionada por una puerta de enlace se puede agrupar como sigue:
Enrutamiento de puerta de enlace: Enrutamiento de las solicitudes de cliente a los servicios de back-end correctos. Esto proporciona un único punto de conexión para los clientes y ayuda a desacoplar los clientes de los servicios.
Agregación de puerta de enlace: Agregación de varias solicitudes en una sola solicitud, para reducir el intercambio de mensajes entre el cliente y el back-end.
Descarga con puertas de enlace. Una puerta de enlace puede descargar de funcionalidades a los servicios de back-end, como la terminación SSL, la autenticación, las listas de direcciones IP permitidas o la limitación de velocidad de cliente.
Las puertas de enlace de API son un patrón de diseño de microservicios general. Se pueden implementar mediante una serie de tecnologías diferentes. Probablemente la implementación más común es implementar un enrutador perimetral o un proxy inverso, como Nginx, HAProxy o Traefik, dentro del clúster.
Otras opciones incluyen:
Azure Application Gateway o Azure API-Management, que son servicios administrados que residen fuera del clúster. Actualmente está en versión beta un controlador de entrada de la puerta de enlace de aplicaciones.
Azure Functions Proxies. Los servidores proxy pueden modificar las solicitudes y las respuestas y enrutar las solicitudes en función de direcciones URL.
El tipo de recurso Entrada de Kubernetes abstrae las opciones de configuración de un servidor proxy. Funciona junto con un controlador de entrada, que proporciona la implementación subyacente de la entrada. Hay controladores de entrada para Nginx, HAProxy, Traefik y Application Gateway (versión preliminar), entre otros.
El controlador de entrada controla la configuración del servidor proxy. A menudo requieren archivos de configuración complejos, que pueden ser difíciles de ajustar si no es un experto, por lo que el controlador de entrada es una buena abstracción. Además, el controlador de entrada tiene acceso a la API de Kubernetes, por lo que puede tomar decisiones inteligentes sobre enrutamiento y equilibrio de carga. Por ejemplo, el controlador de entrada Nginx omite al proxy de red kube-proxy.
Por otro lado, si necesita control absoluto sobre la configuración, puede omitir esta abstracción y configurar manualmente el servidor proxy.
Un servidor proxy inverso es un posible cuello de botella o un único punto de error, por lo que siempre debe implementar al menos dos réplicas para la alta disponibilidad. Almacenamiento de datos
En una arquitectura de microservicios, los servicios no deben compartir el almacenamiento de datos. Cada servicio debe ser propietario de sus propios datos privados en un almacenamiento lógico independiente, para evitar dependencias ocultas entre servicios. La razón es evitar el acoplamiento involuntario entre servicios, lo que puede suceder cuando los servicios comparten los mismos esquemas de datos subyacentes. Además, cuando los servicios administran sus propios almacenes de datos, pueden usar el almacén de datos adecuado para sus requisitos particulares. Para más información, consulte Diseño de microservicios: consideraciones sobre los datos.
Evite almacenar datos permanentes en el almacenamiento del clúster local, ya que esto ata los datos al nodo. En su lugar:
Use un servicio externo como Azure SQL Database o Cosmos DB. O bien,
Monte un volumen persistente con discos de Azure o Azure Files. Use Azure Files si el mismo volumen debe ser compartido por varios pods.
Espacios de nombres
Use espacios de nombres para organizar los servicios dentro del clúster. Todos los objetos de un clúster de Kubernetes pertenecen a un espacio de nombres. De forma predeterminada, cuando se crea un nuevo objeto, este se coloca en el espacio de nombres default. Pero es una buena práctica crear espacios de nombres más descriptivos para ayudar a organizar los recursos del clúster.
En primer lugar, los espacios de nombres ayudar a evitar colisiones de nomenclatura. Cuando varios equipos implementan microservicios en el mismo clúster, posiblemente con cientos de microservicios, se hace difícil de administrar si todos se incluyen en el mismo espacio de nombres. Además, los espacios de nombres permiten:
Aplicar restricciones de recursos a un espacio de nombres para que el conjunto total de pods asignados a ese espacio de nombres no pueda superar la cuota de recursos del espacio de nombres.
Aplicar directivas en el nivel de espacio de nombres, incluidas las directivas de RBAC y seguridad.
Para una arquitectura de microservicios, considere la organización de los microservicios en contextos limitados y la creación de espacios de nombres para cada contexto limitado. Por ejemplo, todos los microservicios relacionados con el contexto limitado "Pedidos" podrían ir en el mismo espacio de nombres. Como alternativa, cree un espacio de nombres para cada equipo de desarrollo.
Coloque los servicios auxiliares en su propio espacio de nombres independiente. Por ejemplo, podría implementar Elasticsearch o Prometheus para la supervisión de clústeres o Tiller para Helm.
Consideraciones sobre escalabilidad
Kubernetes admite el escalado horizontal en dos niveles:
Escalado del número de pods que se asigna a una implementación. Escalado de los nodos del clúster, para aumentar los recursos de proceso totales disponibles para el clúster.
Aunque puede escalar horizontalmente los pods y los nodos manualmente, se recomienda usar el escalado automático para minimizar la posibilidad de que los servicios se queden con recursos escasos en cargas elevadas. Una estrategia de escalado automático debe tienen en cuenta los pods y los nodos. Si solo escala horizontalmente los pods, podría alcanzar los límites de recursos de los nodos. Escalado automático de pods
Horizontal Pod Autoscaler (HPA) escala los pods en función de la CPU y la memoria observadas o de métricas personalizadas. Para configurar el escalado horizontal de pods, especifique una métrica de destino (por ejemplo, el 70% de CPU) y el número mínimo y máximo de réplicas. Debe realizar una prueba de carga de los servicios para averiguar estas cifras.
Un efecto secundario del escalado automático es que los pods podrían crearse o expulsarse con más frecuencia, a medida que se producen eventos de escalado horizontal y reducción horizontal. Para mitigar los efectos de esto:
Use sondeos de preparación para que Kubernetes sepa cuándo está listo un pod nuevo para aceptar tráfico. Use presupuestos de interrupciones de pods para limitar el número de pods que se puede expulsar de un servicio a la vez.
Escalado automático del clúster
El escalador automático del clúster escala el número de nodos. Si no se pueden programar pods debido a restricciones de recursos, el escalador automático del clúster aprovisionará más nodos. (Nota: La integración entre AKS y el escalador automático del clúster está actualmente en versión preliminar).
Mientras que HPA examina los recursos reales consumidos u otras métricas de la ejecución de pods, el escalador automático del clúster aprovisiona nodos para pods que no están programados todavía. Por lo tanto, examina los recursos solicitados, como se especifica en la especificación de pods de Kubernetes para una implementación. Use pruebas de carga para ajustar estos valores.
No se puede cambiar el tamaño de máquina virtual después de crear el clúster, por lo que debe realizar algún planeamiento inicial de capacidad para elegir un tamaño de máquina virtual adecuado para los nodos de agente cuando se crea el clúster. Consideraciones sobre disponibilidad Sondeos de estado
Kubernetes define dos tipos de sondeo de mantenimiento que puede exponer un pod:
Sondeo de preparación: indica a Kubernetes si el pod está listo para aceptar solicitudes.
Sondeo de ejecución: indica a Kubernetes si se debería quitar un pod e iniciar una nueva instancia.
Al pensar en los sondeos, es útil recordar cómo funciona un servicio en Kubernetes. Un servicio tiene un selector de etiqueta que coincide con un conjunto de pods (cero o más). Kubernetes equilibra el tráfico a los pods que coinciden con el selector. Solo los pods que se iniciaron correctamente y que están en buen estado recibirán tráfico. Si se bloquea un contenedor, Kubernetes elimina el pod y programa un reemplazo.
En ocasiones, un pod puede no estar listo para recibir tráfico aunque el pod se inició correctamente. Por ejemplo, puede haber tareas de inicialización, en las que la aplicación que se ejecuta en el contenedor carga elementos en la memoria o lee datos de configuración. Para indicar que un pod está correcto pero no está listo para recibir tráfico, defina un sondeo de preparación.
Los sondeos de ejecución controlan el caso de un pod que sigue en ejecución, pero está en mal estado y se debe reciclar. Por ejemplo, suponga que un contenedor da servicio a solicitudes HTTP, pero se bloquea por algún motivo. El contenedor no se bloquea, pero ha dejado de servir solicitudes. Si define un sondeo de ejecución HTTP, el sondeo dejará de responder y esto informa a Kubernetes para reiniciar el pod.
Estas son algunas consideraciones al diseñar los sondeos:
Si el código tiene un tiempo de inicio elevado, hay un riesgo de que un sondeo de ejecución notifique un error antes de que finalice el inicio. Para evitar esto, use la configuración initialDelaySeconds, que retrasa el inicio del sondeo.
Un sondeo de ejecución no ayuda a menos que reiniciar el pod lo restaure a un estado correcto. Puede usar un sondeo de ejecución para mitigar bloqueos inesperados o fugas de memoria, pero no hay ningún interés en reiniciar un pod que va a producir inmediatamente un nuevo error.
A veces se usan sondeos de preparación para comprobar los servicios dependientes. Por ejemplo, si un pod tiene una dependencia en una base de datos, el sondeo de ejecución podría comprobar la conexión de base de datos. Sin embargo, este enfoque puede crear problemas inesperados. Un servicio externo podría no estar disponible temporalmente por algún motivo. Esto hará que el sondeo de preparación genere un error para todos los pods del servicio, causando la eliminación de todos ellos del equilibrio de carga y así crear errores en cascada ascendentes. Un enfoque mejor consiste en implementar un control de reintentos en el servicio, para que el servicio se pueda recuperar correctamente de errores transitorios.
Restricciones de recursos
La contención de recursos puede afectar a la disponibilidad de un servicio. Defina restricciones de recursos para los contenedores, para que un único contenedor no pueda sobrecargar los recursos de clúster (memoria y CPU). Para recursos que no están en contenedores, como los subprocesos o las conexiones de red, considere el uso del patrón Bulkhead para aislar los recursos.
Utilice cuotas de recursos para limitar los recursos totales permitidos para un espacio de nombres. De este modo, el front-end no puede dejar sin recursos a los servicios de back-end o viceversa. Consideraciones sobre la seguridad Control de acceso basado en roles (RBAC)
Kubernetes y Azure tienen mecanismos de control de acceso basado en rol (RBAC):
El control de acceso basado en rol de Azure controla el acceso a los recursos de Azure, incluida la capacidad de crear nuevos recursos de Azure. Los permisos se pueden asignar a usuarios, grupos o entidades de servicio. (Una entidad de servicio es una identidad de seguridad utilizada por las aplicaciones).
El control de acceso basado en rol de Kubernetes controla los permisos para la API de Kubernetes. Por ejemplo, la creación de pods y la enumeración de pods son acciones que se pueden autorizar (o denegar) a un usuario mediante RBAC. Para asignar permisos de Kubernetes a los usuarios, puede crear roles y enlaces de rol:
Un rol es un conjunto de permisos que se aplican dentro de un espacio de nombres. Los permisos se definen como verbos (obtener, actualizar, crear, eliminar) en los recursos (pods, implementaciones, etc).
Un enlace de rol asigna usuarios o grupos a un rol.
También hay un objeto ClusterRole, que es similar a un rol, pero se aplica a todo el clúster en todos los espacios de nombres. Para asignar usuarios o grupos a un objeto ClusterRole, cree un objeto ClusterRoleBinding.
AKS integra estos dos mecanismos de RBAC. Cuando se crea un clúster de AKS, puede configurarlo para usar Azure AD para la autenticación de usuario. Para más información sobre cómo configurar esta opción, consulte Integración de Azure Active Directory con Azure Kubernetes Service.
Una vez configurado, un usuario que desea acceder a la API de Kubernetes (por ejemplo, mediante kubectl) debe iniciar sesión con sus credenciales de Azure AD.
De forma predeterminada, un usuario de Azure AD no tiene acceso al clúster. Para conceder acceso, el administrador del clúster crea enlaces de rol que hacen referencia a usuarios o grupos de Azure AD. Si un usuario no tiene permisos para una operación determinada, se producirá un error.
Si los usuarios no tienen acceso de forma predeterminada, ¿cómo tiene permisos el administrador del clúster para crear los enlaces de rol en primer lugar? Un clúster de AKS realmente tiene dos tipos de credenciales para llamar al servidor de API de Kubernetes: usuario del clúster y administrador del clúster. Las credenciales de administrador del clúster otorgan acceso completo al clúster. El comando az aks get-credentials --admin de la CLI de Azure descarga las credenciales de administrador del clúster y las guarda en el archivo kubeconfig. El administrador del clúster puede utilizar este archivo kubeconfig para crear roles y enlaces de rol.
Dado que las credenciales de administrador del clúster son muy potentes, utilice RBAC de Azure para restringir su acceso:
El "rol de administrador del clúster de Azure Kubernetes Service" tiene permisos para descargar las credenciales de administrador del clúster. Solo se debe asignar este rol a los administradores del clúster.
El "rol de usuario del clúster de Azure Kubernetes Service" tiene permisos para descargar las credenciales de usuario del clúster. Se puede asignar este rol a los usuarios que no son administradores. Este rol no otorga permisos específicos sobre los recursos de Kubernetes del clúster; simplemente permite que un usuario se conecte al servidor de API.
Al definir las directivas de RBAC (en Kubernetes y Azure), piense en los roles de la organización:
¿Quién puede crear o eliminar un clúster de AKS y descargar las credenciales de administrador? ¿Quién puede administrar un clúster? ¿Quién puede crear o actualizar los recursos de un espacio de nombres?
Es una buena práctica delimitar el ámbito de los permisos de RBAC de Kubernetes por espacio de nombres, mediante roles y enlaces de roles, en lugar de utilizar objetos ClusterRoles y ClusterRoleBindings.
Por último, queda la pregunta de qué permisos tiene el clúster de AKS para crear y administrar recursos de Azure, como equilibradores de carga, redes o almacenamiento. Para autenticarse a sí mismo con las API de Azure, el clúster usa a una entidad de servicio de Azure AD. Si no se especifica una entidad de servicio al crear el clúster, se crea una automáticamente. Sin embargo, es una buena práctica de seguridad crear la entidad de servicio en primer lugar y asignarle permisos de RBAC mínimos. Para más información, consulte Entidades de servicio con Azure Kubernetes Service. Administración de secretos y credenciales de aplicaciones
Las aplicaciones y los servicios a menudo necesitan credenciales para conectarse a servicios externos, como Azure Storage o SQL Database. El desafío consiste en proteger estas credenciales y que no se filtren.
Para los recursos de Azure, una opción es usar identidades administradas. La idea de una identidad administrada es que una aplicación o un servicio tienen una identidad que se almacena en Azure AD y usan esta identidad para autenticarse con un servicio de Azure. La aplicación o el servicio tienen una entidad de servicio creada en Azure AD y se autentican mediante tokens de OAuth 2.0. El proceso en ejecución llama a una dirección de host local para obtener el token. De este modo, no es necesario almacenar contraseñas ni cadenas de conexión. Puede utilizar identidades administradas en AKS mediante la asignación de identidades a pods individuales, con el proyecto aad-pod-identity.
Actualmente, no todos los servicios de Azure admiten la autenticación con identidades administradas. Para obtener una lista, consulte Servicios de Azure que admiten la autenticación de Azure AD.
Incluso con identidades administradas, probablemente necesitará almacenar algunas credenciales u otros secretos de aplicación, ya sea para servicios de Azure que no admiten identidades administradas, servicios de terceros o claves de API. Estas son algunas opciones para almacenar secretos de forma segura:
Azure Key Vault. En AKS, puede montar uno o más secretos de Key Vault como un volumen. El volumen lee los secretos de Key Vault. El pod, a continuación, puede leer los secretos al igual que en un volumen normal. Para más información, consulte el proyecto Kubernetes-KeyVault-FlexVolume en GitHub.
El pod se autentica mediante una identidad de pod (descrita anteriormente) o mediante el uso de una entidad de servicio de Azure AD junto con un secreto de cliente. Se recomienda el uso de identidades de pod porque el secreto de cliente no es necesario en ese caso.
HashiCorp Vault. Las aplicaciones de Kubernetes se pueden autenticar con HashiCorp Vault mediante identidades administradas de Azure AD. Consulte HashiCorp Vault speaks Azure Active Directory (HashiCorp Vault se comunica con Azure Active Directory). Puede implementar el propio almacén en Kubernetes, pero es aconsejable ejecutarlo en un clúster dedicado independiente del clúster de la aplicación.
Secretos de Kubernetes. Otra opción es usar secretos de Kubernetes. Esta opción es la más fácil de configurar pero tiene algunos desafíos. Los secretos se almacenan en etcd, que es un almacén distribuido de pares clave-valor. AKS cifra etcd en reposo. Microsoft administra las claves de cifrado.
El uso de un sistema como HashiCorp Vault o Azure Key Vault proporciona varias ventajas, como:
Control centralizado de los secretos.
Garantías de que todos los secretos se cifran en reposo.
Administración de claves centralizada.
Control de acceso a los secretos.
Auditoría
Seguridad del pod y el contenedor
Esta lista ciertamente no es exhaustiva, pero estos son algunos procedimientos recomendados para proteger los pods y los contenedores:
No ejecute contenedores en modo con privilegios. El modo con privilegios otorga a un contenedor acceso a todos los dispositivos del host. Puede establecer una directiva de seguridad del pod para no permitir que los contenedores se ejecuten en modo con privilegios.
Cuando sea posible, evite ejecutar procesos como root dentro de los contenedores. Los contenedores no proporcionan un aislamiento completo desde la perspectiva de la seguridad, por lo que es mejor ejecutar un proceso de contenedor como un usuario sin privilegios.
Almacene las imágenes en un registro privado de confianza, como Azure Container Registry o Docker Trusted Registry. Use un webhook de validación de admisión en Kubernetes para asegurarse de que los pods solo pueden extraer imágenes desde el registro de confianza.
Examine las imágenes en busca de vulnerabilidades conocidas, mediante una solución de análisis como Twistlock y Aqua, que están disponibles en Azure Marketplace.
Automatice la aplicación de revisiones de imágenes con ACR Tasks, una característica de Azure Container Registry. Una imagen de contenedor se compone de capas. Las capas de base incluyen la imagen del sistema operativo y las imágenes del marco de trabajo de la aplicación, como ASP.NET Core o Node.js. Los desarrolladores de aplicaciones normalmente crean de modo ascendente las imágenes de base y otros desarrolladores del proyecto las mantienen. Cuando se aplican revisiones de modo ascendente a estas imágenes, es importante actualizar, probar y volver a implementar las propias imágenes para no dejar vulnerabilidades de seguridad conocidas. ACR Tasks puede ayudar a automatizar este proceso.
Consideraciones de implementación (CI/CD)
Estos son algunos objetivos de un proceso de CI/CD sólido para una arquitectura de microservicios:
Cada equipo puede compilar e implementar los servicios que posee de forma independiente, sin afectar ni interrumpir a otros equipos.
Antes de implementar en producción una nueva versión de un servicio, se implementa en entornos de desarrollo, pruebas y control de calidad para su validación. Se aplican pruebas de calidad en cada fase.
Una nueva versión de un servicio puede implementarse en paralelo con la versión anterior.
Hay en vigor directivas de control de acceso suficientes.
Para cargas de trabajo en contenedor, puede confiar en las imágenes de contenedor que se implementan en producción.
