Archivo

Posts Tagged ‘Apache’

Introdución a Kubernetes: Orquestando dockers

Resultado de imagen de kubernetesEn anteriores entradas vimos una introducción a docker, además de cómo crearlos y manternerlos.

Pero, ¿cómo los gestionamos y utilizamos? Hay diferentes herramientas para orquestar docker, como swarn, apache mesos o kubernetes. En esta entrada nos vamos a centrar en la herramienta que google donó al software libre en 2015: kubernetes. A Google siempre le ha gustado hacer trabajar a otros y que éstos le aporten contenidos: maps, youtube, etc…. Y no iba a ser diferente con kubernetes, una de las herramientas que tiene ahora mismo más desarrolladores y commits.

Kubernetes consta de diferentes componentes que nos ayudan a gestionar nuestros contenedores docker, como dns, red, proxy, monitorización, apis, scheduler, etc. La instalación es bastante complicada, pero vamos a ver dos formas que nos la facilitan: minikube y kubeadm.

Minikube levanta máquinas virtuales con todos los componentes para que funcione kubernetes. Podemos elegir virtualbox, kvm, hyperv… Es muy sencillo y nos servirá para probarlo. Es poco operativo porque levanta los contenedores dentro de las máquinas virtuales, con la limitación que pueden tener éstas de memoria o espacio.

Kubeadm nos levanta en local contenedores docker con los componentes de kubernetes y se conecta al demonio local de docker.

En avanttic tenemos un cluster con dos nodos de kubernetes instalados con kubeadm, los llamamos kubernetes1 y kubernetes 2, vamos a ver unos ejemplos.

Selection_027

Primero vamos a ver unos conceptos importantes:

  • Deployment: es el contenedor docker que vamos a desplegar que contiene la aplicación. Por ejemplo un servidor web.
  • Pod: un pod es cada unidad de Deployment que tenemos funcionando. Con kubernetes gestionamos cuantos pods queremos levantar de cada aplicación.
  • Services: son los servicios que exponemos que hacen referencia a los PODS

Vamos a desplegar una aplicación, por ejemplo, un servidor web o un weblogic que podemos descargar de nuestro repositorio docker de avanttic https://hub.docker.com/u/avanttic. Como estos últimos son privados por tener licencias, vamos a probar con un apache.

Leer más…

Categorías:WebLogic Etiquetas: , , ,

Escalado de privilegios – Apache/OHS, permisos y granularidad insuficiente

escalera El errante viaje del profesional que se dedica a la consultoría esta repleto de curiosidades, poder ver tantas casas diferentes, métodos, preocupaciones y un sinfín de quehaceres hace que las pequeñas partes homogéneas resalten dentro de esa heterogeneidad. Normativas, estándares, auditorías de seguridad, cada cual más ensortijada.

En lo que a la parte de seguridad atañe, la costumbre más global es:

  • Acceso root prohibido.
  • Auditar todos los accesos o “switch” entre usuarios.
  • Guardar todo el historial.
  • Bits uid, gid, desactivados (muchas veces no puedes ni usar el ping).
  • Particiones “comunes” montadas con noexec.
  • etc.

La mayoría de estos aspectos son razonables, de hecho, particularmente opino que todavía podría elevarse el modo “paranoico”; pero en muchas ocasiones los árboles no nos dejan ver el bosque. En abundantes sistemas nos podemos encontrar que por un lado, se lleva una excelente tarea de auditoría, prevención y seguridad, pero por el otro se descuidan aspectos muy básicos: las ‘capabilities‘ de seguridad que nos proporciona el sudo y su dejada configuración.

Desventuradamente he tenido la ocasión de encontrarme, de manera recurrente, una configuración insuficientemente granulada de las reglas de sudo que permiten autenticas “atrocidades”; éstas quizá pueda atribuirse a descuidos, desidia, comodidad, desconocimiento…

Presentamos un escenario real, donde un usuario sin prácticamente permisos, puede llegar a maximizarlos de una manera mayúscula a partir de una mala configuración del sudoers.

Como de costumbre, adentrémonos a la parte práctica:

Sistema con usuario de servicio sin privilegios (o por ejemplo, operador), sin posibilidad de root, en una máquina con un apache corriendo por el puerto 80, sin privilegios para modificar la configuración del servicio pero con la posibilidad de levantar, parar o reiniciar el proceso.

La primera cosa sobrante a destacar, es que se debería evitar utilizar servicios que tengan que asociarse a puertos privilegiados (inferiores a 1024) ya que esto obliga a levantar el proceso de escucha con usuario privilegiado; maneras de evitarlo hay varias, establecer una capa frontal con un balanceador (o similar), mapeo de puertos, iptables, etc.

Comprobamos como está el apache (httpd):

986345609-apache_root_proc

Vemos que el proceso padre con PID 1725 está levantado con un uid de root y los procesos hijo como apache. Esto es necesario, como se ha comentado, para poder hacer el bind al puerto 80:

2459772857-listen_80_apache

Leer más…