Categories
General In detail

Algunas cosas de AWS que quizás no conoces

Aunque los competidores están empezando a coger carrerilla, decir hoy en día que Amazon Web Services es el proveedor de cloud más utilizado, con más funcionalidades y servicios interesantes es como decir que el cielo es azul. AWS se ha transformado en un monstruo en el que probablemente casi nadie puede estar al día de todos los cambios y funcionalidades en detalle que va adoptando. En este post vamos a ver algunas de las funcionalidades y características de AWS que probablemente si no has trabajado un poco con AWS no conozcas.
post

ALIAS

En route 53 podemos crear registros DNS con ALIAS, no penséis que Amazon ha reinventado el protocolo DNS ni nada por el estilo. Ésta característica ha salido por un lado porque al apex de un dominio (raíz), no se le puede asignar un registro CNAME y esto es un problema en un entorno cloud dónde las IPs no son fijas y todo puede cambiar. A parte también interesa tener registros DNS que apunten a componentes de AWS (como por ejemplo un ELB) y que en caso de que cambie la IP del componente en cuestión el registro sea actualizado.
Al crear un registro DNS , podemos configurar que sea de tipo ALIAS y el componente al que apunta, ésto nos permite apuntar a componentes con IP cambiante y a parte poder configurar un apex de un dominio como un registro que aunque sea de tipo A, es dinámico.

EC2 Metadata

Aunque probablemente todos los que hemos trasteado un poco con EC2 vemos que mágicamente se nos configuran algunos parámetros de la máquina automáticamente como el hostname, se ejecuta el user-data que le hemos pasado, se crea un usuario estándar con nuestra clave pública,… ¿De dónde proviene todo esto? ¿Como puedo recoger toda esta información y actuar si me preparo una AMI de zero?
La respuesta está en el servicio de metadatos, el servicio de metadatos es un servicio http que se encuentra en la dirección 169.254.169.254 de cada máquina. Si ejecutamos por ejemplo:

curl http://169.254.169.254/latest/meta-data/

Podremos ver todos los metadatos relacionados con la instancia. Si ejecutamos:

curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

Podremos ver la clave pública con la que AWS nos configura el usuario ec2-user.
Con ésto podemos ejecutar nuestros propios scripts para que nuestro servidor arranque con las configuraciones que nos interesen del meta-data. Otra posibilidad es instalar cloud-init, el cual nos permite configurar los parámetros del meta-data cómo queremos que se comporten. Las AMIs oficiales de AWS llevan cloud-init instalado por defecto.

ASG Termination Policy

En los autoscaling groups de Amazon se puede configurar la política para de terminar las máquinas virtuales. Por defecto siempre se borra la que más cerca de llegar a un numero entero de horas del Launch Configuration más viejo del Availability Zone en el que tengamos más máquinas.
Si queremos cambiar éste comportamiento, podemos cambiar la termination policy a uno de estos parámetros:

  • OldestInstance – Dentro del Auto Scaling group seleccionado (el que tenga más instancias) se selecciona la instancia más vieja.
  • NewestInstance – Se termina la instancia más recientemente creada.
  • OldestLaunchConfiguration – Se termina la instancia del Launch Configuration más viejo.
  • ClosestToNextInstanceHour – Se termina la instancia que más a punto está de cumplir un múltiplo de 60 minutos.
  • Default – Se termina con la política por defecto explicada más arriba.

ASG Health Checks

En los AutoScaling Groups, AWS utiliza health checks para detectar si una instancia está en buen estado. En caso de que una instancia no esté respondiendo, es terminada y en caso de que sea necesario escalará agregando nuevas instancias. Por defecto el health check se coge del estado general de EC2 y aunque es la configuración recomendada, en caso de tener un Elastic Load Balancer asociado al AutoScaling Group se puede hacer que los health checks se cojan del estado que está detectando el balanceador. Ésta última configuración puede dar raíz a problemas, imaginemos que de repente nos llega mucha carga y nuestras instancias dejan de responder un código 200 a los balanceadores que hemos configurado como healthcheck, ¿que pasará? El resultado será que en vez de escalar nuestro AutoScaling Group las instancias que no respondían serán eliminadas teniendo el efecto contrario al deseado. Más información aquí.

Multi-Factor Authentication

Con Multi-Factor Authentication, AWS permite la autenticación con dos factores, por un lado tenemos el usuario y contraseña y por el otro tenemos el segundo factor que puede ser con dispositivos virtuales como Google Authenticator, o la virtual MFA de AWS. También se puede utilizar Gemalto como dispositivo físico, el cual  nos dará aún más seguridad que los dispositivos virtuales.

AWS Direct Connect

ADC_Connection_Map_v3_screen
Aunque el diagrama lo dice casi todo, DirectConnect trata de tener conectividad directa hacia los Centros de Datos de AWS, ¿como se hace esto? Pues básicamente debemos tirar un enlace a uno de los routers de Direct Connect y tenemos ancho de banda dedicado con AWS, la parte de conectividad del router a los centros de datos de AWS es gestionado por AWS. +Info aquí

Aplicación para dispositivos móviles

Y para terminar, y más como curiosidad que otra cosa, vemos que existe una aplicación de AWS para móviles. Se puede encontrar en el PlayStore de Android y en el AppStore de Apple. Después de probar la aplicación si que vemos que aunque es útil para visualizar el estado de nuestra infraestructura, no nos sirve para poder lanzar nueva infraestructura o cambiar configuraciones.
Esto es todo cloudadmins, si tienen cualquier duda o sugerencia pongan sus comentarios!
Saludos,
Oriol Marti
Cloud Admin

Categories
General Monitoring

Battle Cloud Providers

microsoft-azure-logo
Almacenamiento y computación son los recursos que más consumimos habitualmente en nuestros proveedores IaaS. Otros servicios como balanceo de carga, servicio de colas, monitorización de rendimiento de los recursos, etc son considerados en el momento de escoger pero son secundarios en el grueso de la factura final. Estos servicios compiten en costes, rendimiento y disponibilidad. Es sorprendente como recientemente hemos visto anuncios de distintas compañías anunciando reducciones de precios en servicios clave.

A raíz de estos movimientos es fácil no saber hacía que proveedor dirigirse o que criterio debe prevalecer a la hora de utilizar los distintos servicios que nos proporcionan. Han surgido herramientas como PlanForCloud que pueden ayudarnos en esta tarea. También le debemos dar importancia a las SLA’s que nos ofrecen y al rendimiento de las plataformas que desplegamos en servicios IaaS/PaaS, para ello contamos con aplicaciones como de CloudSleuth, nos permite ver de forma detallada varias métricas que nos ayudan elegir que proveedor es el adecuado para nuestros requerimientos.

Cloud Pricing Trends
Ante tanta variedad se nos puede hacer complicado la gestión de tantos servicios, más aún si contamos con varios proveedores, se encuentran en crecimiento plataformas como ECmanaged o eNovance, que nos permiten llevar una administración centralizada de ellos. También herramientas de código abierto como Hydra que nos permiten una mayor flexibilidad y menor coste para llevar a cabo estas tareas. Hemos encontrado este post muy interesante para valorar los distintos proveedores existentes actualmente. A día de hoy AWS sigue siendo la referencia a seguir, veremos como evolucionan las grandes compañías ante tanta competitividad.
Top Public Clouds Used

Categories
General

¿Hacia dónde volaran las nubes en 2014?

Es el momento del año para hacer balance de como ha ido el 2013 y hacer previsiones para este 2014 que empezará en breve. También es el momento del año en el que muchos nos ponemos hacer predicciones sobre los temas más calientes que nos pueden afectar, desde cloudadmins no vamos a ser menos y repasaremos a continuación las posibles tendencias que pueden revolucionar el sector TIC en 2014.

  •  NFV & SDN (Network Functions Virtualisation & Software Defined Networks) SDN se está posicionando como solución de entornos productivos cada vez más flexibles, eficientes y altamente programables, es el caso de iniciativas abanderadas por OpenStack y OpenDaylight Projects. Al mismo tiempo es posible que NFV gane importancia y dirija nuevas funcionalidades en nuestros ISP permitiendo administrar los servicios dentro del cloud, reduciendo drásticamente costes e incrementando su agilidad. Estas pueden ser las tecnologías más disruptivas del próximo año.
  • Big Data: el uso de dispositivos BYOD y la explosión de contenido multimedia de altas prestaciones esta causando grandes retos en el ámbito del almacenamiento de datos y como definir su estrategia. En 2014 debemos preguntarnos cuestiones fundamentales sobre los volumen de datos ¿Cuáles son los objetivos de la arquitectura de almacenamiento? ¿Estamos almacenando los datos correctos y de forma adecuada? ¿De que modo les podemos sacar el mayor provecho? ¿Pueden ir de la mano con técnicas de BI (Bussines Intelligence) y/o Inteligencia Operacional? Para los que estamos más verdes en este tema la siguiente presentación puede introducirnos y aclararnos el concepto de Big Data: “Runaway complexity in Big Data. And a plan to stop it
  • Private Cloud: Estos últimos años hemos visto en el sector TIC la adopción de forma exponencial de tecnologías Cloud. Nadie duda ya de los beneficios nos aporta: pago por uso, flexibilidad, disponibilidad, etc… pero las preocupaciones en cuanto a la seguridad y privacidad siguen presentes. Aspectos que hacen que muchas organizaciones requieran que se implemente una nube privada, antes de dar el salto hacía proveedores de servicios cloud públicos.
  • LXC & Configuration Management: A estas alturas podemos decir que ya hemos vivido la eclosión de herramientas destinadas a la gestión de la configuración (puppet, chef, salt, etc..) y vemos como emerge una nueva forma de gestionar recursos a través de LXC (containers). Algunas herramientas como puppet ya se han subido al carro, dónde Dockers se posiciona dando solución al nuevo enfoque de los sistemas frente a los restos del “futuro” PaaS.

Para finalizar os dejo una píldora con las mejores herramientas, en el ámbito de la seguridad, de este 2014 gracias a Team Cymru. Buen despegue de año!

Categories
General Security

El cuento del Cloud que quería ser seguro

El 4 de junio asistimos a la primera UOC SEC-CON, en ella participaron ponentes de renombre. Se trataron temas diversos, desde la evolución del Cloud en los últimos años, los ataques de ciberseguridad registrados mas célebres y en que consiste el trabajo de los Mossos en delitos cometidos en este ámbito.
El cuerpo de policia de los Mossos hizo hincapié en la dificultad al recoger evidencias válidas y además Vicente Diaz, Chema Alonso y David Barroso describieron los últimos ataques de más renombre (Stuxnet, Duqu, Flame, hacktivismo).  Este último nos descubrío Tails, un sistema muy aconsejable para los que quieren mantener su privacidad navegando o utilizando equipos de terceros.
Mientras Jesús Luna, Head of DEEDS’ Security Research Group at TU Darmstadt,  especializado en el área de seguridad en la nube y miembro de Cloud Security Alliance contó en forma de cuento  como habían convergido distintas tecnologías virtualización, WebServices, redes de alta velocidad) para llegar a ofrecer los servicios Cloud que conocemos actualmente: IaaS, PaaS, SaaS, etc…

Repasamos las distintas modalidades de cloud existentes:

  • híbrido
  • privado
  • público
  • comunitario

Y  los beneficios que todos conocemos que nos brinda:

  • escalabilidad 
  • pago por uso
  • disponibilidad
  • flexibilidad
  • deslocalización

Pero topamos con la seguridad, según Jesús Luna, la seguridad y la confianza siguen siendo los principales inhibidores para la adopción de tecnologías Cloud entre PyMES europeas. La elección de Proveedores de Servicios Cloud (CSP)  es motivada a menudo en valoraciones sobre los acuerdos en el nivel de servicio (SLA) y sus costes, además recientemente también se basan en aspectos de seguridad y/o privacidad. Desafortunadamente es muy poco común que un CSP especifique con detalle los niveles de seguridad asociados a sus servicios, de este modo no es posible que los clientes tomen decisiones relevantes basándose en directivas de seguridad.

Con el objetivo de evitar estas carencias Cloud Security Alliance propone utilizar especificaciones concretas de seguridad en las SLA de los acuerdos con los CSP, llamándolas “Security Level Agreements” o SecLAs. De este modo sería posible crear ecosistemas Cloud confiables, siendo deseable desarrollar técnicas que nos permitan medir i cuantificar estas características para poder compararlas, negociar y predecir posibles agujeros de seguridad.

Jesús Luna afirmo con firmeza que en un futuro próximo las SLA’s (SecLAs) van a determinar las claves de la relación de los servicios Cloud (CSP) con sus usuarios, también puso énfasis sobre el prospero porvenir de los proveedores de SECaaS.