RBAC en AZURE y como consultar su configuración

RBAC (Roled based access control) es una característica de seguridad utilizada para controlar el acceso en función de los roles del usuario en una organización, es decir, considerando sus funciones dentro de esa organización. En grandes organizaciones es una manera clásica de organizar los permisos, basandose en las competencias, autoridad y responsabilidad de un puesto de trabajo.

Una cualidad de RBAC es su dinamismo, pues el control de acceso a una función se le concede a un rol y la integración en dicho rol de una persona puede variar con el tiempo, así como los permisos asociados a un rol. Se contrapone a los métodos de acceso clásico en donde los permisos de acceso se otorgan o revocan a un usario objeto a objeto.

En AZURE disponemos de una implementación RBAC para los recursos y una serie de roles predefinidos. Los roles en AZURE se pueden asignar a usuarios, grupos, y aplicaciones, y a nivel de suscripciones, grupos de recursos, o recursos. Como vemos las opciones son muy amplias.

20160524_RBAC_AZURE_Paso01

Los roles básicos son tres: propietario, contribuidor o colaborador, y lector. El propietario tiene acceso completo a los recursos, incluido los permisos para poder delegar el acceso a otros. El colaborador es igual al propietario pero no puede otorgar acceso a otros. El lector puede ver sólo los recursos.

De estos tres roles heredan otra serie de roles para recursos concretos. En este enlace hay una lista completa de los roles base en Azure y sus funciones.

Sin embargo se pueden generar tantos roles con permisos personalizados como sean necesarios. Para crearlos se puede hacer vía Azure PowerShell, la interfaz de cliente de línea de Azure (CLI) o la API REST. En este enlace tenéis más información y ejemplos de cómo realizarlo.

Acceso al listado de permisos de cada rol

Una forma de comprobar que permisos tiene cada rol es a través del portal de AZURE. Entráis dentro de una suscripción, grupo de recursos o recurso, y veréis un icono de personas en la parte superior derecha:

20160524_RBAC_AZURE_Paso02

Al pulsarlo aparece el panel de Usuarios. Pulsais en roles:

20160524_RBAC_AZURE_Paso03

Y os aparece el listado de roles disponibles:

20160524_RBAC_AZURE_Paso04

Seleccionamos el rol que nos interese comprobar sus permisos, y nos aparece la pestaña de miembros del Rol, con un botón para consultar el listado de permisos:

20160524_RBAC_AZURE_Paso05Una vez en el listado podemos ampliar información de cada grupo de acciones pulsando sobre la entrada correspondiente:

20160524_RBAC_AZURE_Paso06

Y dentro de ella en cada acción individual:

20160524_RBAC_AZURE_Paso08

A este nivel es útil la información que ofrece el icono de saber más en cada entrada con una explicación de cada acción lo que supone:

20160524_RBAC_AZURE_Paso09

Para saber más sobre como dar de alta, baja o consultar miembros de los roles, podéis consultar el siguiente enlace.

Balanceo de carga con nginx a dos WebAPP de Azure

En el post anterior vimos como instalar un servidor nginx. Una de las capacidades que tiene ngin-x es ser un potente servidor proxy, utilizado como balanceador de carga. En este post vamos a ver como usarlo para balancear la carga de dos WebAPPs (podrían ser tantas como fueran necesarias). Este escenario presenta una particularidad que obliga a modificar ligeramente el procedimiento normal para esta operación.

Partimos de una máquina linux con ngin-x instalado, tal como se vió en el post anterior.

Además vamos a crear dos WebAPPs simples, con un mensaje que nos diferencie entre cada una de ellas por ejemplo, tal como se ve en las siguientes imágenes:

20160505_NGINX_WebAPP_Paso02

20160505_NGINX_WebAPP_Paso03

A continuación vamos a configurar ngin-x siguiendo las pautas normales. Entramos al servidor linux en una consola de comando y editamos el fichero de congiguración con nano por ejemplo:

sudo nano /etc/nginx/nginx.conf

Y modificamos el script para que quede como el siguiente código:

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
     worker_connections 768;
     # multi_accept on;
}

http {
     upstream bloqueprimerproxy {
          server xxURL1xx.azurewebsites.net;
          server xxURL2xx.azurewebsites.net;
     }

     server {
          listen 80;
          server_name   localhost;

          location / {
               proxy_pass http://bloqueprimerproxy;
               proxy_set_header  X-Real-IP  $remote_addr;
          }
     }
}

En donde xxURL1xx.azurewebsites.net y xxURL2xx.azurewebsites.net son las URLs de las dos WebAPPs a balancear.

Grabamos el código y reiniciamos el servicio ngin-x con:

sudo service nginx restart

El script anterior sería la forma normal de balancear dos WEBs con ngin-x. Pero si lo probamos ahora obtendremos el siguiente error:

20160505_NGINX_WebAPP_Paso01

Ésto se debe a que Azure App Service usa cookies para ARR (Application Request Routing). Es necesario asegurarse que el proxy pasa la cabecera de forma correcta a la WebAPP para que ésta identifique la petición correctamente.

Para esto editamos de nuevo el fichero de configuración y lo dejamos como sigue:

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
     worker_connections 768;
     # multi_accept on;
}

http {
     upstream bloqueprimerproxy {
         server localhost:8001;
         server localhost:8002;
     }

     upstream servidor1 {
         server xxURL1xx.azurewebsites.net;
     }

     upstream servidor2 {
         server xxURL2xx.azurewebsites.net;
     }

     server {
          listen 80;
          server_name   localhost;

          location / {
               proxy_pass http://bloqueprimerproxy;
               proxy_set_header    X-Real-IP    $remote_addr;
          }
     }

     server {
          listen 8001;
          server_name   servidor1;

          location / {
               proxy_set_header Host xxURL1xx.azurewebsites.net;
               proxy_pass http://servidor1;
          }
     }

     server {
          listen 8002;
          server_name   servidor2;

          location / {
               proxy_set_header Host xxURL2xx.azurewebsites.net;
               proxy_pass http://servidor2;
          }
     }
}

En donde igual que antes xxURL1xx.azurewebsites.net y xxURL2xx.azurewebsites.net son las URLs de las dos WebAPPs a balancear.

En este script lo que hacemos es aplicar un doble proxy, de tal forma que balanceamos la entrada contra el mismo ngin-x, atacando por los puertos 8001 y 8002, del cual encaminamos a las WebAPPs, pero añadiendo a la cabecera la URL real de la WebAPP.

Tras grabar el script y reiniciar el servicio ngin-x, si entramos al mismo veremos que nos balancea de una a otra web sin problema.

Para saber más sobre los modos de balanceo disponibles en ngin-x podeis consultar este enlace.

 

 

Instalación de NGINX en una VM Linux Ubuntu 16.04 en Azure

En éste post vamos a ver como instalar nginx en una máquina virtual Linux Ubuntu 16.04 LTS en Azure. Se trata de uno de los mejores servidores HTTP y proxy inversos, además de ser también un proxy IMAP/POP3. Es de código abierto.

Vamos a suponer que ya tenemos desplegada la máquina virtual linux en un estado básico. Si no, como resumen, los pasos serían:

– Crear una máquina virtual desde la galería con Ubuntu 16.04. Puedes ver mi post sobre creación de VM linux.
– Cambiar el puerto ssh por defecto. Tienes instrucciones para hacerlo en Azure en mi post al respecto.
– Actualizar el sistema, conectándonos a una sesión de consola y ejecutando:

sudo apt-get update
sudo apt-get upgrade

Éste paso siempre es recomendable antes de instalar algún paquete (salvo servidores de producción con paquetes productivos previos que habrá que estudiar si es o no conveniente).

Como vamos a instalar un servidor HTTP, si disponéis de un servidor http previo como Apache, tenéis que desinstalarlo para evitar conflictos.

Una vez con la máquina lista para instalar nginx, desde la consola ssh ejecutamos:

sudo apt-get install nginx

Y por último iniciamos el servicio nginx con:

sudo systemctl start nginx

Comprobamos que el servicio está activo con:

sudo service nginx status

Lo que ofrece información del servicio que será similar a la siguiente pantalla:

20160505_Install_NGINX_Paso02

Ya tendríamos instalado nginx, con su configuración por defecto al puerto 80. Si entramos a la máquina por dicho puerto nos aparecerá la siguiente página de cortesía:

20160505_Install_NGINX_Paso03

Para más información sobre nginx podéis acceder a su página en éste enlace.

Cambio de puertos SSH y XRDP en una máquina virtual Linux en Azure

Una recomendación básica de seguridad es cambiar los puertos de conexionado por defecto de un sistema para los distintos servicios de comunicaciones disponibles. Vamos a ver como cambiar el puerto ssh y xrdp en una máquina virtual Linux en Azure.

Cambio de puerto ssh

Nada más crear la máquina virtual, el puerto por defecto es el 22. Conectamos a la máquina por medio de su IP o DNS público con un cliente tipo Putty a través de dicho puerto. Editamos el fichero de configuración con nano por ejemplo:

sudo nano /etc/ssh/sshd_config

Y modificamos donde pone el puerto 22 por el valor que deseemos (por ejemplo yo he puesto 40167):

20160401_CambioSSH_Paso02

Ahora es necesario reiniciar el servicio ssh. Ejecutamos:

sudo service ssh restart

Cerramos la sesión remota que estamos ejecutando, que todavía irá por el puerto 22. Ahora tenemos que editar la regla de seguridad en el panel de control de la máquina virtual para reflejar el cambio de puerto. Para ello, buscamos la máquina en nuestra suscripción de Azure, por ejemplo, en mi caso se llama f23uh4733:

20160401_CambioSSH_Paso04

Pulsamos en la opción de reglas de seguridad de entrada:

20160401_CambioSSH_Paso05

Y hacemos doble clic sobre la regla actual del puerto 22:

20160401_CambioSSH_Paso06

Y modificamos el valor del puerto 22 al puerto definido en el fichero de configuración:

20160401_CambioSSH_Paso07

Pulsando grabar tras la modificación. La regla tardará unos segundos en estar aplicada.

Instalación de un escritorio remoto y cambio de puerto xrdp

Ahora vamos a instalar un escritorio remoto. Ésto será necesario si nuestra imagen de Linux es tipo servidor por ejemplo. Hay que tener en cuenta que xrdp en Ubuntu desde la versión 12.04LTS no soporta Gnome Desktop, por lo que usaremos xfce.

Primero instalamos xrdp, para lo que ejecutamos el siguiente comando en la línea de terminal:

sudo apt-get install xrdp

20160401_CambioSSH_Paso08

Una vez concluida la instalación de xrdp, instalamos xfce, ejecutando el comando:

sudo apt-get install xfce4

20160401_CambioSSH_Paso09

El siguiente paso es configurar xrdp para que use xfce. Ejecutamos el siguiente comando:

echo xfce4-session >~/.xsession

20160401_CambioSSH_Paso10

Una vez instalado el escritorio, vamos a cambiar el puerto por defecto de conexión remota. Usamos un editor, por ejemplo nano, para modificar el fichero de configuración de xrdp. Ejecutamos el comando:

sudo nano /etc/xrdp/xrdp.ini

Y modificamos el puerto con el valor deseado, en éste caso por ejemplo al puerto 40168:

20160401_CambioSSH_Paso12

Grabamos los cambios y reiniciamos el servicio xrdp para que surtan efecto, mediante el siguiente comando:

sudo service xrdp restart

20160401_CambioSSH_Paso13

Una vez tenemos configurado el puerto, al igual que antes, tenemos que crear la regla de seguridad que nos permita acceder. Para ello volvemos al listado de reglas de entrada, y pulsamos el botón añadir:

20160401_CambioSSH_Paso14

Y añadimos una regla indicando el puerto destino que hayamos configurado en el paso anterior:

20160401_CambioSSH_Paso15

Pulsamos grabar y esperamos a que la regla se aplique. Posteriormente ya podemos abrir una conexión por escritorio remoto contra la máquina por el puerto:

20160401_CambioSSH_Paso16

Nos tendremos que identificar con un usuario UNIX. Si no hemos creado ninguno, el usuario administrador nos serviría:

20160401_CambioSSH_Paso17

Y accederíamos al escritorio de la máquina Linux:

20160401_CambioSSH_Paso18

 

Public_IP

Dirección pública de una VM de Azure

Cada máquina virtual que despleguemos en Azure, por defecto, tiene asignada una IP pública, a través de la cual podemos acceder a la misma. Es posible, posteriormente, tanto modificar los puertos de acceso como restringir, en ciertos casos, su acceso público.

IP y DNS de una máquina virtual

Para acceder a la IP pública de una máquina virtual creada en modelo ARM, abre el panel de la máquina desde el listado de máquinas virtuales:

20160326_IPDNSPublico_Paso01

En el panel pricipal ya aparece la IP pública, y si estuviera configurado, su DNS. En caso de que el DNS aparezca sin definir, se puede especificar uno pulsando sobre el enlace:

20160326_IPDNSPublico_Paso02

En el panel de dirección IP Pública podemos observar y copiar de forma fácil tanto la IP como el DNS.

20160326_IPDNSPublico_Paso03

Si pulsamos en configuración, accedemos a las opciones específicas de IP. Podemos establecer que se le asigne una IP estática a la máquina virtual (por defecto es dinámica), así como definir un DNS dentro del dominio de nuestra región geográfica:

20160326_IPDNSPublico_Paso04

Una vez guardado los cambios, en unos segundos se habrán aplicado y estarán disponibles públicamente.

 

Linux_Azure_Creation

Crear una máquina virtual Linux en Azure

Dentro del marketplace de Azure nos encontramos múltiples imágenes listas para desplegar. Entre ellas están varias distribuciones de Linux creadas por varias compañías, con varios paquetes ya preinstalados llegado el caso.

Creación de una máquina virtual Linux

Vamos a ver el proceso completo de aprovisionamiento de una máquina virtual (IaaS) con una imagen de Canonical de Ubuntu Server 15.10.

Paso 1

Entramos en nuestra suscripción de Azure y pulsamos sobre máquinas virtuales:

20160311_CreaciónVM_Paso01

Paso 2

Pulsamos en agregar nueva máquina virtual:

20160311_CreaciónVM_Paso02

Paso 3

Buscamos por Ubuntu y seleccionamos la imagen Ubuntu Server 15.10 de Canonical:

20160311_CreaciónVM_Paso03

Paso 4

Nos aparece la descripción de la imagen, en donde podremos seleccionar si la queremos en modo clásico o administrador de recursos. Vamos a elegir administrador de recursos. Puedes consultar las diferencias en éste enlace. Pulsamos crear para iniciar el proceso de provisión:

20160311_CreaciónVM_Paso04

Paso 5

Rellenamos los datos básicos de la máquina, con especial atención a la zona geográfica de despliegue y el grupo de recursos al que asignarla. Seleccionar la ubicación más cercana a donde queráis dar el servicio o aquella en donde tengáis todo vuestro CPD virtual.

Respecto al grupo de recursos, recordad que todo lo que metáis dentro no se reiniciará de forma simultánea ante mantenimientos, por lo que su uso es para situaciones de alta disponibilidad.

En éste paso definiréis el usuario y contraseña root, así que asegurad que los datos son correctos.

Una vez relleno todo pulsáis aceptar.

20160311_CreaciónVM_Paso05

Paso 6

Ahora seleccionar el tamaño, lo que define el coste de la máquina. Elegid el que necesitéis en función del uso estimado. La serie DS, con discos SSD, son apropiados para servicios LAMP por ejemplo.

20160311_CreaciónVM_Paso06

Paso 7

Toca configurar opciones adicionales, como la red, tipo de almacenamiento y otros. Al terminar pulsad aceptar. Si no conocéis todavía estos conceptos en Azure, las opciones por defecto os servirán para empezar.

20160311_CreaciónVM_Paso07

Paso 8

Se presenta un resumen del proceso y se solicita una última confirmación. Si está todo bien, pulsar aceptar y se comenzará a aprovisionar la máquina. Si no, podéis volver hacia atrás para corregir.

Creación VM Ubuntu

En el área de notificaciones tendréis un aviso del progreso del proceso, al igual que en el panel principal.

Una vez concluido el despliegue, lo que puede llevar unos 5 a 10 minutos, podéis conectar por SSH con un cliente tipo Putty, usando la IP pública de la máquina y contra el puerto 22, con el usuario root definido en las opciones básicas del paso 5.

Sin embargo dicha configuración por defecto no es la más segura. En un próximo post veremos como cambiar los puertos por defecto e instalar un escritorio para acceso remoto. Posteriormente veremos como configurar al servidor para convertirlo es un stack LAMP.