Viesgo DevOps Devolucion S1 Arquitectura - v1.2

DevOps VIESGO
Sesión 1: Estructura de
cuentas y demás recursos
Fecha 06-07-2020
Estructura de Cuentas. Organización
Root
Corporativo
Distribucion
Renovables
VProduccion
Cross
Leyenda
POC
Cuentas estándar
Comunicaciones
Cuentas PoC
Operaciones
Cuentas de Operaciones
Estructura de Cuentas. Organización
Rama Nombre cuenta Alias email ID
Root vsgawsrootaccount vsgawsrootaccount vsgaws.rootaccount@viesgo.com 915890720717
Corporativo cor-dev vsgaws-cor-dev vsgaws.cor.dev@viesgo.com 960614880755
Corporativo cor-pre vsgaws-cor-pre vsgaws.cor.pre@viesgo.com 054484717316
Corporativo cor-pro vsgaws-cor-pro vsgaws.cor.pro@viesgo.com 413812990487
Distribucion dis-dev vsgaws-dis-dev vsgaws.dis.dev@viesgo.com 183098313647
Distribucion dis-pre vsgaws-dis-pre vsgaws.dis.pre@viesgo.com 884037555636
Distribucion dis-pro vsgaws-dis-pro vsgaws.dis.pro@viesgo.com 121228366233
Renovables rnv-dev vsgaws-rnv-dev vsgaws.rnv.dev@viesgo.com 277492409504
Renovables rnv-pre vsgaws-rnv-pre vsgaws.rnv.pre@viesgo.com 197245442544
Renovables rnv-pro vsgaws-rnv-pro vsgaws.rnv.pro@viesgo.com 981609831772
Vproduccion vpr-dev vsgaws-vpr-dev vsgaws.vpr.dev@viesgo.com 423712042760
Vproduccion vpr-pre vsgaws-vpr-pre vsgaws.vpr.pre@viesgo.com 960252234463
Vproduccion vpr-pro vsgaws-vpr-pro vsgaws.vpr.pro@viesgo.com 993055504552
Cross xxx-dev vsgaws-xxx-dev vsgaws.xxx.dev@viesgo.com 617952550872
Cross xxx-ply vsgaws-xxx-ply vsgaws.xxx.ply@viesgo.com 133116317474
Cross xxx-pre vsgaws-xxx-pre vsgaws.xxx.pre@viesgo.com 087085150646
Cross xxx-pro vsgaws-xxx-pro vsgaws.xxx.pro@viesgo.com 992937034862
POC vsgawspocsaccount vsgawspocsaccount vsgaws.pocsaccount@viesgo.com 373590949523
Comunicaciones vsgawscommsaccount vsgawscommsaccount vsgaws.commsaccount@viesgo.com 841613174390
Operaciones vsgawsicaccount vsgawsicaccount vsgaws.icaccount@viesgo.com 600517573284
Operaciones vsgawsmonaccount vsgawsmonaccount vsgaws.monaccount@viesgo.com 619215983135
Operaciones vsgawssegauditaccount vsgawssegauditaccount vsgaws.segauditaccount@viesgo.com 525888378357
Direccionamiento
• El espacio de direccionamiento asignado a la Nueva Arquitectura de Viesgo AWS es
10.112.0.0/15 (10.112.0.0 a 10.113.255.255)
• Se ha troceado dicho espacio en base a Rangos de distintos tamaños, según necesidades. La
mayoría de ellos se utilizan sólo desde 1 cuenta.
• Se realiza una gestión dinámica de la asignación de direccionamiento a 3 niveles: Rango, VPC
y APP
10.112.0.0/22 10.112.4.0/22 10.112.8.0/22
10.112.12.0/22 10.112.16.0/20 Renovables DEV 10.112.32.0/20 Renovables PRE 10.112.48.0/20 Renovables PRO
Operaciones Comunicación PoC
10.112.64.0/18 Distribución DEV
10.112.128.0/18 Distribución PRE
10.112.192.0/18 Distribución PRO
10.113.0.0/19 VProducción DEV 10.113.32.0/19 VProducción PRE
10.113.64.0/19 VProducción PRO 10.113.96.0/19 Corporativo DEV
10.113.128.0/19 Corporativo PRE 10.113.160.0/19 Corporativo PRO
10.113.192.0/20 Cross DEV 10.113.208.0/20 Cross PRE 10.113.224.0/20 Cross PRO 10.113.240.0/23 10.113.244.0/22
10.113.242.0/24
10.113.243.0/24 10.113.248.0/21
Direccionamiento
Nombre Rango CIDR
Operaciones 10.112.0.0/22
• Las VPC siempre van asociadas a un determinado Rango
Comunicaciones 10.112.4.0/22 • Las Aplicaciones (APPs) van siempre asociadas a una VPC
PoC
Reserved
10.112.8.0/22
10.112.12.0/22
• Existen 3 cuentas estándar por cada Área de Negocio, 1 por cada
RenovablesDEV 10.112.16.0/20 entorno (DEV, PRE y PRO). Cross tiene además PLY.
RenovablesPRE 10.112.32.0/20 • Las cuentas estándar, utilizan 1 único Rango con 1 única VPC
RenovablesPRO 10.112.48.0/20
DistribucionDEV 10.112.64.0/18 • En la VPC de una cuenta estándar se aprovisionan todas las
DistribucionPRE 10.112.128.0/18 aplicaciones, cada una con su propio direccionamiento.
DistribucionPRO 10.112.192.0/18
VProduccionDEV 10.113.0.0/19 • Es decir, en la cuenta cor-dev (Corporativo, Desarrollo) sólo se
VProduccionPRE 10.113.32.0/19 desplegarán aplicaciones de Corporativo del entorno de Desarrollo
VProduccionPRO 10.113.64.0/19
CorporativoDEV 10.113.96.0/19
• Se han definido 4 tamaños estándar de Aplicaciones: mini, small,
CorporativoPRE 10.113.128.0/19 médium y big
CorporativoPRO 10.113.160.0/19 • Todas las APPs tienen subredes públicas (Front) y privadas (Back)
CrossDEV 10.113.192.0/20
CrossPRE 10.113.208.0/20 • El número de AZs de cada aplicación puede variar entre 1 y 3
CrossPRO 10.113.224.0/20
Tamaño APP Tamaño de Subredes
AmmDistribucion 10.113.240.0/23
CrossPLY 10.113.242.0/24 mini /28
10.113.243.0/24 small /27
10.113.244.0/22 medium /26
10.113.248.0/21 big /25
Nueva Arquitectura. Características
• Hay 2 tipos de cuentas:
• Estándar de Desarrollo, asociadas a Áreas de Negocio (cor-dev, cor-pre, cor-pro, dis-dev, dis-
pre, dis-pro, rnv-dev, rnv-pre, rnv-pro, vpr-dev, vpr-pre, vpr-pro, xxx-dev, xxx-ply, xxx-pre, xxx-
pro)
• Cuentas de Operaciones: resto de cuentas, su nombre empieza por “vsgaws” y termina en
“account”
• A nivel de Seguridad, todas las Aplicaciones (APP) tienen 2 Grupos, por compatibilidad con la vieja
Infra, cuyo nombre termina en “-GAPP” y ”-GAPP2”. También tienen 2 Roles , cuyo nombre
termina en “-RAPP” y “-RDeployAtlas”.
• El Role “-RAPP” Gestiona la Seguridad Local de la Aplicación, utilizado por los Usuarios
• El Role “-RDeployAtlas” Gestiona la Seguridad Delegada, utilizado por la herramienta de
Integración Continua Atlas.
• El Role “-RAPP” contiene los mismos permisos que los Grupos “-GAPP” + ”-GAPP2”
• Lo normal es que los Grupos “-GAPP” + ”-GAPP2” no tengan usuarios asignados
• Sólo se admiten usuarios Locales, cuando se trata de usuarios programáticos.
• Los usuarios existentes están definidos en el Directorio Activo
• Aplicaciones (APP): Todas las aplicaciones están nombradas de manera estándar, su nombre está
compuesto del identificador del Área de Negocio (cor, dis, rnv, vpr, xxx, ope, com, poc), un
identificador numérico del sistema de 3 cifras, un guion y el identificador del entorno (dev, ply,
pre, pro), todo en minúsculas. Ejemplo: cor007-dev, dis008-pre, ope005-pro.
• Nombrado de recursos: Todos los recursos en las cuentas de AWS empiezan por “A” + el nombre
de la APP (sin guion) y todo en mayúsculas. Ejemplo: ACOR007DEV, ADIS008PRE, AOPE005PRO.
(ver estándares de nomenclatura).
• Subredes: Toda Aplicación tendrá sus propias Subredes (en Frontend, que serán públicas y en
Backend, que serán privadas). El número de subredes dependerá del nº de AZs de la Aplicación.
• RouteTables: Cada aplicación tiene 2 RouteTables:
• -RTBPRI: lleva asociadas las subredes de Backend de la Aplicación
• -RTBPUB: lleva asociadas las subredes de Frontend de la aplicación
• Security Groups: Toda Aplicación tiene definidos los siguientes Security Groups:
• BACKEND: Para los recursos desplegados en las Subredes de Backend (excepto RDS)
• FRONTEND: Para los recursos desplegados en las Subredes de Frontend
• BBDD: Para los recursos de tipo RDS, que irán siempre en las Subredes de Backend
• DMZ: Para permitir acceso externo. Sólo aplicará en recursos desplegados en Frontend
• INTRA-VPC: Para securizar los accesos entre aplicaciones de la misma VPC.
• Buckets: Cada aplicación dispondrá de un Bucket específico, que estará formado por “vsgaws.” + el
estándar del nombrado de recursos (pero en minúsculas) + “-s3”. Ejemplo: vsgaws.acor007dev-s3
• Existe 1 Bucket de Intercambio, creado sólo en las cuentas “-dev” y compartido con las
cuentas “-pre” y “-pro”. Se llama “intercambio” + nombre del área de negocio. Ejemplo:
intercambiocor. En cada Bucket de Intercambio se crea una carpeta específica por cada
Aplicación, a la que sólo tiene permisos la aplicación asociada (en sus 3 entornos). El nombre
se corresponde con el APP_NAME en minúsculas. Ejemplo: cor007_alfresco-corp,
cor011_websitecorporate
• Uso de etiquetas: Todo recurso debe estar etiquetado con varias etiquetas (ver estándares)
• Etiqueta APP_NAME, debe ser aplicada a todo recurso existente con valores válidos. Sirve
entre otras cosas para identificar a qué aplicación pertenece dicho recurso y por tanto para
poder repartir los Costes entre las distintas Aplicaciones.
• Al utilizar un modelo de cuentas y VPCs compartidas entre muchas Aplicaciones, es
imprescindible el Tagueo con APP_NAME. Los valores siempre estarán establecidos en
mayúsculas.
• KeyPair: Por cada aplicación se genera una KeyPair, que se guarda en el Bucket “aope003pro-
credenciales” de la cuenta vsgawssegauditaccount.
• Backup: Se utiliza el servicio AWS Backup. Se crea un Vault específico por cada Aplicación. También
se crean 2 planes de Backup x Aplicación, basados en el uso de etiquetas (para RDS y para resto de
recursos)
• Afecta a todos los recursos que tengan definida la etiqueta “Backup” coincidiendo con el
nombre de la APP (en mayúsculas o en minúsculas). Recursos no RDS.
• Afecta a todos los recursos que tengan definida la etiqueta “Backup” coincidiendo con el
nombre de la APP (en mayúsculas o en minúsculas) + “-RDS” o “-rds”. Recursos RDS.
Es imprescindible etiquetar correctamente con la etiqueta “Backup” todos los Volúmenes, EFS, RDS y
tablas DynamoDB.
• Parameter Store: Toda aplicación que haga uso de ssm deberá respetar la estructura
/Sistema/Entorno. Ejemplo: /COR011/PRE/DatabaseName
• SMTP: Para el envío de emails, se utiliza el servicio SES.
• Se crea un usuario programático por cada Aplicación que necesita enviar emails.
• Se crea en la cuenta de comunicaciones (vsgawscommsaccount), con el nombre terminado en
“-USENDMAILS”, con permiso para el envío de emails.
• Se generan credenciales: SMTPUsername y SMTPPassword. Se guardan en el Parameter Store
de la cuenta vsgawscommsaccount
• Transit Gateway: La primera Aplicación que se aprovisiona de una VPC, se utilizan sus Subnets
para conectar la VPC al Transit Gateway. Esto no se puede hacer en la creación de la VPC, porque
en ese momento no se crean Subnets. Esto es así, porque sólo se puede utilizar una Subnet de
cada Zona.
• En caso de querer eliminar una Aplicación que se estén utilizando sus Subnets para conectar la
VPC al Transit Gateway, primero se deberán sustituir sus Subredes por las de otra Aplicación que se
quede en uso. Una vez sustituidas podría eliminarse la Aplicación.
• Las Subredes que se utilizan para conectar la VPC al Transit Gateway son siempre las de Backend.
• Para todas las Aplicaciones, en el RouteTable “-RTBPRI” se añade una ruta para que el tráfico
"0.0.0.0/0“ se envíe por el Transit Gateway.
• Para todas las Aplicaciones, en el RouteTable “-RTBPUB” se añade rutas para que el tráfico
"10.0.0.0/8“, "172.16.0.0/12“ y "192.168.0.0/16" se envíe por el Transit Gateway. El resto del
tráfico sale por el Internet Gateway.
Comunicaciones. Modelo en estrella
• Interconexión de las VPCs: Basado en Transit Gateway ubicado en la cuenta de comunicaciones
(vsgawscommsaccount)
• Se utiliza el Resource Access Manager (RAM) desde la cuenta de Comunicaciones para compartir el
Transit Gateway con el resto de cuentas.
• La única VPC con Nat Gateway es la de Comunicaciones
• La cuenta de Comunicaciones tiene implementada una solución de Firewall basada en Fortinet
• Todo el tráfico que vaya a un direccionamiento distinto al de la propia VPC es enviado al Transit
Gateway.
• Todo el tráfico que pasa a través del Transit Gateway es inspeccionado.
• El tráfico de salida (fuera de AWS) de todas las VPCs es enviado a través del Transit Gateway al Nat
Gateway de Comunicaciones.
• Para poder filtrar el tráfico entre Aplicaciones que comparten la misma VPC, que no pasará por el
Transit Gateway, se han implementado Security Groups llamados INTRA-VPC por cada Aplicación.
• A través de una herramienta específica, el equipo de Comunicaciones puede añadir o quitar
reglas a dichos Security Groups
• Todos los recursos desplegados en las Subredes de Backend deben utilizar el Security Group
de INTRA-VPC además del que le corresponda.
Acceso a la plataforma AWS
• En la Nueva Arquitectura desaparecen los usuarios nominales en las cuentas AWS
• Todos los usuarios deben autenticarse a través del IdP (Identity Provider) de tipo SAML. En el
caso de viesgo se utiliza ADFS contra el Directorio Activo con las credenciales corporativas.
1. A través del Navegador se accede al Portal de autenticación
2. El portal autentica al usuario
3. El usuario selecciona de entre las opciones acceder a AWS
4. El Portal obtiene la lista de Roles a los que puede acceder dicho usuario y los ofrece en
una lista.
5. El usuario selecciona el Role con el que quiere acceder a AWS
6. En el Navegador le redirige al Servicio SSO de AWS con un Token del IdP
7. Se obtienen credenciales temporales para el Usuario y el Navegador redirige a la Consola
AWS
8. La consola AWS autentica con las credenciales temporales y accede con el Role
especificado en el IdP
• En el Directorio Activo se crea un Grupo por cada Role que deba autenticarse. Estos grupos
llevan el siguiente formato: AWS-<idCuenta>-<NombreRole>
• Ejemplo: AWS-915890720717-AOPE001PRO-ROPERACIONES
• Se agregarán los usuarios necesarios del AD a dicho grupo para permitirles acceso al Role
https://login.app.viesgo.com/adfs/ls/idpinitiatedsignon
• Roles de Operaciones actuales:
Cuenta principal Rol Asociado Descripción
AOPE001PRO-ROPERACIONES Equipo de Arquitectos. Full access todas las cuentas
AOPE001PRO-RREADONLYB Sólo lectura + Billing
AOPE001PRO-RREADONLYNB Sólo lectura. Sin Billing
AOPE001PRO-RBILLINGRO Billing en modo sólo lectura
vsgawsrootaccount AOPE001PRO-ROPEAPLICACION Equipo de Operación. Full access cuentas aplicaciones
AOPE001PRO-RPMOPEB Sólo lectura + Billing + S3 sin Management + Start/Stop
AOPE001PRO-ROPEOFIPRO Equipo de Oficina de Programa. Buckets Intercambio
AOPE001PRO-ROPECIC Equipo Operaciones CiC. Buckets Intercambio
AOPE001PRO-ROPEATOS Equipo Operaciones Atos. Buckets Intercambio
vsgawscommsaccount ACOM001PRO-RWAF Sólo lectura. Sin Billing + WAF
vsgawsicaccount AOPE006PRO-RANSIBLE EC2 sólo lectura
• Todos los Roles de la tabla tienen capacidad de realizar Switch Role sobre el resto de cuentas
• Los siguientes Roles están limitados a las cuentas –dev (Buckets de Intercambio):
• AOPE001PRO-ROPEOFIPRO
• AOPE001PRO-ROPECIC
• AOPE001PRO-ROPEATOS
• Por cada Aplicación que se despliega, se crea un Role de Acceso pensado para los equipos de
Desarrollo/Mantenimiento.
• Todos esos Roles tienen también definida una relación de confianza con ADFS.
• Normalmente se da acceso sólo al Role del entorno más bajo, habitualmente Desarrollo,
pero en ocasiones se trata del entorno de Preproducción cuando no existe Desarrollo.
• Para dar acceso a un Role, basta con solicitar al equipo de Micro Informática la creación
del grupo ADFS asociado al Role
• Todos los usuario del Directorio Activo que se añadan al grupo ADFS creado
anteriormente tendrán acceso al Role asociado
• Quitar acceso a un determinado usuario de un Role es tan simple como solicitar que se le
saque del grupo ADFS asociado al Role
• Toda la gestión de Autenticación y Autorización se centra en el Directorio Activo
• Los Permisos que se conceden a cada Role se gestionan desde la Herramienta de
Automatización.
Funcionalidades Automatizadas
Se han desarrollado las siguientes Funcionalidades Automatizadas con interface de Usuario:
• Alta de cuentas
• Consultas del Direccionamiento
• Capa -1
• Capa 0
• Gestión de Políticas Customizadas
• Gestión de la Seguridad (Local y Delegada)
• Gestión de Grupos
• Creación de Usuarios SMTP
• Creación de Usuarios programáticos S3
• Gestión de Cross Account S3
• Gestión de VPCs Endpoints
• Gestión de Encendidos / Apagados
• Gestión de Backup
• Restauración de Backup
Adicionalmente se han desarrollado scripts que son planificados y que por tanto no tienen
Interface de Usuario:
• Purgado de ficheros de logs de más de 30 días de la planificación de encendidos y apagados
• Purgado de los ficheros de Inventario de más de 30 días
• Purgado de los ficheros de inventario/InfoInstancias de más de 60 días (utilizados para restore)
• Purgado de los ficheros de inventario/InfoRDSs de más de 60 días (utilizados para restore)
• Purgado de los objetos en los Buckets de Intercambio. Elimina con antigüedad superior a los
60 días y notifica con email
• Actualiza el inventario de EC2, RDS y ASG
• Procesamiento de encendidos / apagados
• Recoger la información necesaria para restaurar Instancias y para restaurar RDSs
• Verificar y notificar Backups fallidos
• Verificar y notificar Tags mal definidas que impidan realizar el Backup
• Verificar y notificar errores de Inventario
• Reprocesar los Security Groups de todas las APPs de todas las Cuentas. Es necesario ejecutarlo
cuando se creen nuevas VPCs
Otras Funcionalidades Automatizadas
• A través de la herramienta de Automatización se da acceso a los servicios de Atlas
• Jenkins
• Nexus
• Sonar
• Sólo se enlaza con los servicios existentes de Atlas
• También se da acceso a una pequeña herramienta desarrollada para Comunicaciones que
permite gestionar los permisos IntraVPC
• El acceso está limitado a los Usuarios que pertenezcan al siguiente Grupo:
• AWS-841613174390-ACOM001PRO-RAPP
• Exige Autenticación contra el Directorio Activo
• Funcionalidad de Reglas IntraVPC
• Selecciona fichero de reglas (del equipo local)
• Sube el fichero seleccionado
• Procesa el fichero de Reglas subido, actualizando los Security Groups para añadir o quitar
accesos a determinadas aplicaciones respecto al Security Group denominado INTRA-VPC
• Recopilar todas las reglas definidas actualmente en base a los Security Groups INTRA-VPC
existentes
Modelo de Automatización
Todas las tareas Automatizadas se realizan a través de servidor de Automatización.
• Se utiliza la AWS Command CLI
• Los desarrollos funcionales están implementados en bash shell
• Se ha implementado una capa de Presentación en AJAX + PHP
• Existe una capa intermedia implementada en PHP que permite invocar la ejecución del los
scripts y recoger el resultado de las ejecuciones para poder ser mostrados.
• El uso de la herramienta exige autenticación contra el Directorio Activo y que el usuario
pertenezca al grupo AWS-915890720717-AOPE001PRO-ROPERACIONES
• La duración de la Sesión está configurada en 1 hora.
Detalle Funcionalidades Automatizadas
Alta de cuenta
Datos de entrada:
• Nombre de Cuenta: nombre de la cuenta. P.E. cor-dev
• Lista de distribución: email que se proporciona asociado a la cuenta. Viesgo utiliza una lista de
distribución
• Nombre del Sistema: (por compatibilidad con la vieja Infra. No se utiliza)
Tareas que realiza:
• Valida que el nombre se ajuste a los estándares de Viesgo
• Crea la cuenta
• Ubica la cuenta en la Organización
• Configura la cuenta para permitir hacer Switch Role sobre OrganizationAccountAccessRole
• Añade un nuevo profile a nivel AWS para la nueva cuenta
• Crea el Alias de la Cuenta
• Configura la política de Contraseñas de la Cuenta
• Crea el Role ReadOnlyForCloudynViesgo y le asigna permisos de Sólo lectura
• Crea el Role OrganizationAccountOperacionesRole, le asigna permisos Full Access y establece
relación de confianza con cuenta vsgawsrootaccount para permitirle hacer Switch Role al Role
AOPE001PRO-ROPERACIONES.
Alta de cuenta
Tareas que realiza (continuación):

• Crea el Role OrganizationAccountROBRole, le asigna permisos sólo lectura + Billing y establece
relación de confianza con cuenta vsgawsrootaccount para permitirle hacer Switch Role al Role
AOPE001PRO-RREADONLYB.
• Crea el Role OrganizationAccountRONBRole, le asigna permisos sólo lectura + No Billing y
establece relación de confianza con cuenta vsgawsrootaccount para permitirle hacer Switch
Role al Role AOPE001PRO-RREADONLYNB.
• Crea el Role OrganizationAccountBillingRORole, le asigna permisos de Billing en modo sólo
lectura y establece relación de confianza con cuenta vsgawsrootaccount para permitirle hacer
Switch Role al Role AOPE001PRO-RBILLINGRO.
• Crea el Role OrganizationAccountAnsibleRole, le asigna permisos de EC2ReadOnly y establece
relación de confianza con cuenta vsgawsicaccount para permitirle hacer Switch Role al Role
AOPE006PRO-RANSIBLE.
• Crea el Role OrganizationAccountOpeAplicacionRole, le asigna permisos Full Access y
establece relación de confianza con cuenta vsgawsrootaccount para permitirle hacer Switch
Role al Role AOPE001PRO-ROPEAPLICACION. Este Role sólo se crea en cuentas que sean
estándar, quedan excluidas las de Operaciones y Comunicaciones
Alta de cuenta

• Crea el Role OrganizationAccountBillingPMOPEBRole, le asigna permisos sólo lectura + Billing
+ S3 sin Management + Start/Stop y establece relación de confianza con cuenta
vsgawsrootaccount para permitirle hacer Switch Role al Role AOPE001PRO-RPMOPEB.
• Crea el Role OrganizationAccountComsRole, le asigna permisos sólo lectura + WAF y establece
relación de confianza con cuenta vsgawscommsaccount para permitirle hacer Switch Role al
Role ACOM001PRO-RWAF.
• Crea el Role CompassRole y le asigna permisos de Sólo lectura
• Crea el Role OrganizationAccountMonRole, le asigna permisos sólo lectura y establece
relación de confianza con cuenta vsgawsrootaccount para permitirle hacer Switch Role al
Grupo Monitorizacion, que contiene al usuario programático AOPE001PRO-
UMONITORIZACION.
• Crea el Role OrganizationAccountOpeCiCRole, le asigna la Policy
OrganizationAccountOpeCiCRole y establece relación de confianza con cuenta
vsgawsrootaccount para permitirle hacer Switch Role al Role AOPE001PRO-ROPECIC. Limitado
a las cuentas –dev
Alta de cuenta

• Crea el Role OrganizationAccountOpeAtosRole, le asigna la Policy
OrganizationAccountOpeAtosRole y establece relación de confianza con cuenta
vsgawsrootaccount para permitirle hacer Switch Role al Role AOPE001PRO-ROPEATOS.
Limitado a las cuentas –dev
• Crea el Role OrganizationAccountOpeOfiProRole, le asigna la Policy
OrganizationAccountOpeOfiProRole y establece relación de confianza con cuenta
vsgawsrootaccount para permitirle hacer Switch Role al Role AOPE001PRO-ROPEOFIPRO.
Limitado a las cuentas –dev
Consultas del Direccionamiento
Para la gestión del Direccionamiento la Herramienta de Automatización utiliza un fichero, que

versiona con cada cambio que se realiza.
El fichero se llama VPCs.txt y se encuentra ubicado en la ruta /var/www/data. Se recomienda
NO manipular manualmente.
Actualmente tiene 15 campos, separados por el carácter “:”
• Rango: Nombre del Rango
• CIDRRango: CIDR del Rango
• ACC: Nombre de cuenta
• ACCID: ID de cuenta
• VPCID: VPCID
• VPC: Nombre de la VPC
• CIDRVPC: CIDR de la VPC
• APP: Nombre de la Aplicación. Siempre en minúsculas
• CIDRAPP: CIDR de la APP
• Size: Tamaño de la APP (mini | small | medium | big)
• nAZ: Nº de AZs
• APP_NAME: Tag APP_NAME de la Aplicación. Siempre en mayúsculas
• Modalidad : Tipo de capa 0 (FULL | BI | OB)

• Operación: Servicio de Operación (everis | Atos | CiC | CiC-Atos)
• Slot: Todo el direccionamiento está troceado en /27, ya que es el tamaño mínimo que
ocuparía una APP de 1 sola AZ y tamaño mini. AWS no permite hacer Subnets de tamaño
inferior a /28
Existe un registro (línea del fichero) por cada Slot.
En la gestión dinámica del direccionamiento se busca el primer hueco que se ajuste a los
requisitos de búsqueda, y se reserva rellenando los campos relacionados con la información del
recurso, ya sea Rango, VPC o APP.
Consultas. Esta información se obtiene del fichero VPCs.txt:

• Rangos: Lista los Rangos actuales y sus CIDR
• Todas VPCs y APPs: Lista todas las APPs, con todos los datos asociados. También lista VPCs con
sus datos asociados
• VPCs y APPs X cuenta: Igual a la consulta anterior, pero restringido a la cuenta seleccionada.
• Subnets X cuenta: Obtiene una entrada por cada Subnet de la cuenta seleccionada con la
información asociada
Campos del fichero VPCs.txt

Rango:CIDR:ACC:ACCID:VPCID:VPC:CIDR:APP:CIDR:Size:nAZ:APP_NAME:Modalidad:Operación:Slot
Capa-1
Datos de entrada:
• Cuenta: Se ha de seleccionar alguna de las cuentas existentes
• Rango: Se ha de seleccionar el Rango del que se aprovisionará el direccionamiento de la VPC
• Nombre de VPC
• tamaño de VPC: Se ha de seleccionar el tamaño entre el tamaño máximo del Rango y /27
Tareas que realiza:
• Realiza validación de datos
• Localiza el primer hueco en el direccionamiento del Rango seleccionado que esté libre y se ajuste
al tamaño solicitado. Lo Reserva para la VPC indicada rellenando los campos:
• VPC: Nombre de la VPC
• CIDRVPC: CIDR de la VPC
• Crea la VPC
• Añade los Tags Name y APP_NAME
• Habilita el EnableDnsHostnames y el enableDnsSupport
• Ajusta el InstanceTenancy con el valor default
• Crea el Internet Gateway y lo atacha a la VPC
• Añade los Tags Name y APP_NAME al Internet Gateway
Capa-1

• Crea DHCP Options apuntando a los DNSUNBOUND
• Asocia el DHCP Options a la VPC
• Elimina el DHCP Options previo
• Añade los Tags Name y APP_NAME al DHCP Options
• Se crean VPCEndPoints para S3 y DynamoDB
• Se actualiza la Reserva de la VPC con los siguientes campos:
• ACC: Nombre de la Cuenta
• ACCID: Id de la Cuenta
• VPCID: Id de la VPC
Lotes Capa-1
Tiene doble funcionalidad:

• Permite reprocesar 1 o más de 1 VPC (Capa-1) de manera desatendida.
• Se invoca a ejecutar Capa-1. Se obtienen los parámetros de entrada del fichero VPCs.txt
• Permite consultar la última ejecución de Capa-1 de las VPCs seleccionadas
Datos de entrada:
• Selección de VPCs a reprocesar / Consultar
Capa0
Datos de entrada:
• Cuenta: Se ha de seleccionar alguna de las cuentas existentes
• Nombre Aplicación: nombre APP, cumpliendo los estándares
• APP_NAME: Especificar valor. Debe ir en mayúsculas
• Modalidad: Se ha de seleccionar entre B. Intercambio, Sólo Buckets y Full Capa0
• Operación: Seleccionar servicio de Operación entre everis, CiC, Atos y CiC-Atos
• [Autoriza]: Cuando se reprocesa cambiando la Modalidad o la Operación
• [VPCID]: Sólo cuando la modalidad es FULL
• [Size]: Seleccionar tamaño entre (mini, small, medium y big). Sólo cuando la modalidad es FULL
• [nAZs]: Seleccionar entre los valores disponibles. Sólo cuando la modalidad es FULL
Tareas que realiza:
• Localiza el primer hueco en el direccionamiento de la VPC seleccionada que esté libre y se ajuste al
tamaño solicitado y lo Reserva para la APP indicada rellenando los campos del fichero VPCs.txt:
• APP, CIDR, Size, nAZs, APP_NAME, Modalidad y Operacion
• Crea el Resources Groups
• Crea las RouteTables (-RTBPRI y -RTBPUB)
Capa0

• Añade los Tags Name y APP_NAME a las RouteTables
• Trocea el CIDR de APP en las distintas Subredes, calculando los CIDR de cada Subred
• Crea las subredes
• Asocia las Subredes a las RouteTables
• Configura en los VPCEndpoints existentes de tipo Gateway el uso de la RouteTable “-RTBPRI”
• Crea DB-SubnetGroup
• Localiza la Transit Gateway y verifica si ya tuviera creado el Transit Gateway Attachment
• Si fuera necesario crea TGA utilizando sus Subredes de Backend para la VPC
• Añade el Tag Name
• Crea las rutas
• "0.0.0.0/0“ en el RouteTable “-RTBPRI” por el TransitGateway
• "0.0.0.0/0“ en el RouteTable “-RTBPUB” por el InternetGateway
• "10.0.0.0/8“ en el RouteTable “- RTBPUB” por el TransitGateway
Capa0

• Analiza los Transit Gateway Route Tables para verificar si necesitan Asociar o Propagar el
TGAttachment con el TGRouteTable
• Crea los Security Groups: “-SGPFRN”, “-SGPBND”, “-SGPBDD“, “-SGPDMZ“, “-SGPVPC"
• Crea los filtros necesarios para los Security Groups “-SGPFRN”, “-SGPBND” y “-SGPBDD“:
• CIDR de la APP
• "10.122.0.0/16”
• “10.123.0.0/16”
• “10.124.0.0/16”
• “10.125.0.0/16”
• “10.111.0.0/22”
• “10.140.0.0/16”
• “10.141.0.0/16”
• “10.145.0.0/16“
• CIDR de las demás VPCs. Nunca del VPC propio
• Crea la Key Pair
Capa0

• Crea las Policies
• ${APPID}-PSBLOCKVP: Bloquea la modificación a nivel de VPC, Subnet, etc.
• ${APPID}-PSCNOIAM: Bloquea la modificación a nivel de IAM, sólo admite consultas.
• ${APPID}-PSNOBILLING: Bloque el acceso al Billing
• ${APPID}-PSRESOURCEGROUP: Permite acceder al Resource Group de la APP
• ${APPID}-PMYAPP: Restringe el acceso a recursos que no sean de la APP (en un entorno
compartido), basándose en la etiqueta APP_NAME
• Crea el IdP
• Crea los grupos: ${APPID}-GAPP y ${APPID}-GAPP2
• Crea el Rol ${APPID}-RAPP con la relación de confianza con el IDL
• Asocia las siguientes Policies al Role ${APPID}-RAPP:
• ${APPID}-PSBLOCKVPC, ${APPID}-PSCNOIAM, ${APPID}-PSRESOURCEGROUP, ${APPID}-
PMYAPP
• Asocia las siguientes Policies al Grupo ${APPID}-GAPP :
• ${APPID}-PSBLOCKVPC, ${APPID}-PSCNOIAM, ${APPID}-PSRESOURCEGROUP, ${APPID}-
PMYAPP
Capa0

• Crea Bucket de aplicación
• Le configura los permisos para que sea Privado
• Crea Bucket de Intercambio si la cuenta es de –dev y no existiera
• Crea la carpeta asociada a la Aplicación
• Si la cuenta no es de –DEV, crea el CrossAccount con la cuenta
• Crea Bucket de Log si no existiera
• Crea la carpeta asociada a la Aplicación
• Crea el CrossAccount con la cuenta de Seguridad (vsgawssegauditaccount)
• Se crea la Policy ${APPID}-PSS3APPINT para permitir según casuística acceso a los Buckets de
Aplicación, de Intercambio y de Log
• Se asocia al Grupo ${APPID}-GAPP
• Se asocia al Role ${APPID}-RAPP
• Si la Cuenta es estándar de tipo -dev y no existiera, crea la Policy ${ACCNAME}-PSS3OFIPRO
Capa0

• Asocia la Policy ${ACCNAME}-PSS3OFIPRO al Role OrganizationAccountOpeOfiProRole
• Gestión del la Policy ${ACCNAME}-PSS3OPECIC para el equipo de CiC si la cuenta es de tipo -dev
• Verifica el contenido de la Policy respecto a la carpeta de la APP en el Bucket de Intercambio
• Si el Equipo de Operación de la Aplicación es CiC añade permisos sobre la carpeta
• Si el Equipo de Operación de la Aplicación NO es CiC elimina permisos sobre la carpeta
• Gestión del la Policy ${ACCNAME}-PSS3OPEATOS para el equipo de Atos si la cuenta es de tipo -dev
• Si el Equipo de Operación de la Aplicación es Atos añade permisos sobre la carpeta
• Si el Equipo de Operación de la Aplicación NO es Atos elimina permisos sobre la carpeta
• Crea el CloudFormation de Capa0, donde exporta los valores de los principales recursos.
• Nombre de Stack: ${APPID}-STCAPA0
• Si no existiera, crea el Role ${ACCNAME}-RServiceCatalog
• Si no existiera, crea la Policy ${ACCNAME}-PEtiquetadoVolume
• Si no existiera, crea la Policy ${ACCNAME}-PS3ServiceCatalog
• Asocia al Role ${ACCNAME}-RServiceCatalog las Policies ${ACCNAME}-PEtiquetadoVolume,
${ACCNAME}-PS3ServiceCatalog y AmazonEC2ReadOnlyAccess
Capa0

• Crea un InstanceProfile para el Role ${ACCNAME}-RServiceCatalog y se lo asocia
• Crea el Role AWSBackupDefaultServiceRole
• Le asocia la Policy AWSBackupServiceRolePolicyForBackup
• Le asocia la Policy AWSBackupServiceRolePolicyForRestores
• Crea el Vault específico de la Aplicación para asociarles los Backup, con el nombre de la APP en
mayúsculas
• Crea el Plan genérico de Backup, especificando el Vault anterior.
• Crea una selección de recursos basado en que tengan la etiqueta “Backup” con el valor de la
APP (en mayúsculas o en minúsculas). Ejemplo: Backup=“COR007-DEV”
• Crea el Plan de Backup para RDS, especificando el Vault anterior.
• Crea una selección de recursos basado en que tengan la etiqueta “Backup” con el valor de la
APP (en mayúsculas o en minúsculas) + “-RDS” (o + “-rds”). Ej: Backup=“COR007-DEV-RDS”
Lotes Capa0
Tiene doble funcionalidad:

• Permite reprocesar 1 o más de 1 APP (Capa0) de manera desatendida.
• Se invoca a ejecutar Capa0.
• Se obtienen los parámetros de entrada del fichero VPCs.txt si su Modalidad = FULL
• Se consulta el fichero TAPPs.txt si su Modalidad ≠ FULL
• Permite consultar cualquiera de las ejecuciones de Capa0 de las APPs seleccionadas
Datos de entrada:
• Selección de Apps a reprocesar / Consultar
Fichero TAPPs.txt
En uno de los evolutivos de la Herramienta surgió la necesidad de desplegar Capa0 para

Aplicaciones que sólo tendrían acceso al Bucket de Intercambio o al de Intercambio y Aplicación.
Este tipo de Aplicaciones no consumen direccionamiento, por lo que no tiene sentido registrar su
información en el fichero VPCs.txt, que estaba pensado sólo para el control del direccionamiento.
Por tal motivo se generó el fichero TAPPs.txt, que se encuentra ubicado también en la ruta
/var/www/data. Se recomienda NO manipular manualmente.
Este fichero tiene 1 entrada por cada Aplicación desplegada, mientras que el fichero VPCs.txt sólo
contiene información de las Aplicaciones de tipo FULL (las que tienen direccionamiento).
Actualmente tiene 6 campos, separados por el carácter “:”
• ACC: Nombre de cuenta
• ACCID: ID de cuenta
• APP: Nombre de la Aplicación. Siempre en minúsculas
• APP_NAME: Tag APP_NAME de la Aplicación. Siempre en mayúsculas
• Modalidad : Tipo de capa 0 (FULL | BI | OB)
• Operación: Servicio de Operación (everis | Atos | CiC | CiC-Atos)
Campos del fichero TAPPs.txt
ACC:ACCID:APP:APP_NAME:Modalidad:Operación
Políticas Customizadas
Las Políticas Customizadas que se pueden gestionar están clasificadas en 3 tipos:

• Local: Es una política que se podría aplicar a los Usuarios, a través del Role ${APPID}-RAPP y del
Grupo ${APPID}-GAPP2. Se llamará ${APPID}- PCLnn
• Delegada: Es una política que se podría aplicar al Role ${APPID}-RDeployAtlas para la herramienta
de Integración Continua Atlas. Se llamará ${APPID}- PCDnn
• Global: Es una política que se podría aplicar tanto para la Seguridad Delegada como para la
Seguridad Local (de los Usuarios). Se llamará ${APPID}- PCGnn
Existen 3 funcionalidades para la Gestión de Políticas Customizadas:
• Crear Nueva Policy: Desde el interface de Usuario se genera una lista de los servicios a utilizar. Con
dicha lista se genera la Policy.
• Modificar Policy existente: Desde el interface de Usuario se actualiza la lista de los servicios a
utilizar. Con dicha lista se genera una nueva versión de la Policy existente.
• Eliminar Policy Existente: Tras confirmación se elimina la Policy especificada.
Las Policies se generan para todas las funcionalidades de cada servicio seleccionado. Ej: "rds:*“
Las Policies pueden generarse de tipo Allow y de tipo Deny.
En caso de que la Policy sea de tipo Deny el nombre será: ${APPID}- PCLDnn, ${APPID}- PCDDnn o
${APPID}- PCGDnn.
Políticas Customizadas. Nueva Policy
Datos de entrada:
• ACC: Se ha de seleccionar alguna de las cuentas existentes
• APP: Se ha de seleccionar alguna de las APP existentes para la cuenta
• Tipo de Policy: Se ha de seleccionar el tipo entre: PCL, PCG y PCD
• OPT: Lista de servicios a incluir en la Policy. Separados por punto “.”
• Tipo de Permisos: Se ha de seleccionar entre Allow y Deny
Tareas que realiza:
• Obtiene el numérico a utilizar en el nombre de la Policy. (${APPID}-${Tipo}nn)
• Genera la Policy a partir de los Templates .HeaderNewPolicy.txt y .FooterNewPolicy.txt
Políticas Customizadas. Modificar Policy
Datos de entrada:
• Nombre de Policy: Se ha de seleccionar la Policy a Modificar
• OPT: Lista de servicios con los que actualizar la Policy. Separados por punto “.”
• Tipo de Permisos: Se ha de seleccionar entre Allow y Deny
Tareas que realiza:
• Obtiene la información de la Policy y el número de versiones existentes
• Si el número de versiones es mayor de 4 elimina la Versión más antigua
• Se genera nueva versión de la Policy a partir de los Templates .HeaderNewPolicy.txt y
.FooterNewPolicy.txt
Políticas Customizadas. Eliminar Policy
Datos de entrada:
• Nombre de Policy: Se ha de seleccionar la Policy a Eliminar
Tareas que realiza:
• Verifica que la Policy no esté en uso
• Elimina todas las versiones existentes distintas de la default
• Elimina la Policy
Gestión de la Seguridad
Desde esta Utilidad se gestiona de manera independiente la Seguridad Local y la Seguridad

Delegada
Se dispone de varias funcionalidades de Seguridad:
• GetSecurity: Obtiene las Policies actuales asociadas a los Roles de Seguridad Local y de
Seguridad Delegada. También obtiene las Políticas customizadas disponibles para esta
Aplicación
• SecurityL: Gestiona la Seguridad Local
• SecurityD: Gestiona la Seguridad Delegada
Gestión de la Seguridad. GetSecurity
Datos de entrada:
Tareas que realiza:
• Obtiene las Policies asociadas al Role ${APPID}-RAPP con nombre Normalizado Viesgo.
• Obtiene las Policies asociadas al Role ${APPID}-RDeployAtlas con nombre Normalizado Viesgo.
• Obtiene las Policies Customizadas compatibles con la Seguridad Local y nombre Normalizado
Viesgo.
• Obtiene las Policies Customizadas compatibles con la Seguridad Delegada y nombre
Normalizado Viesgo.
Datos que devuelve:
• Devuelve 4 registros que contienen los datos anteriores:
• LPOLL=${LPOLL}
• LPOLD=${LPOLD}
• LPOLCL=${LPOLCL}
• LPOLCD=${LPOLCD}
Gestión de la Seguridad. SecurityLocal
Datos de entrada:
• Lista Opciones: PSS, FULL, READONLY, NOBILL, PS, KMS, NOSUPPORT, NOIAMFULL (la lista podrá
tener más de 1 opción, separada por “.”
• Lista de policies : Lista de Policies Customizadas separadas por “.”
Tareas que realiza:
• Obtiene los siguientes datos de la APP: APP_NAME, Modalidad, Operación y ACCID
• Obtiene el nombre de la Carpeta del Bucket de Intercambio asociada a la APP
• Si no existiera, crea la Policy ${APPID}-PSBLOCKVPC: Bloquea la modificación a nivel de VPC,
Subnet, etc.
• Si no existiera, crea la Policy ${APPID}-PSCNOIAM: Bloquea la modificación a nivel de IAM, sólo
admite consultas.
• Si no existiera, crea la Policy ${APPID}-PSNOBILLING: Bloque el acceso al Billing
• Si no existiera, crea la Policy ${APPID}-PSRESOURCEGROUP: Permite acceder al Resource Group de
la APP

• Si no existiera, crea la Policy ${APPID}-PMYAPP. Si ya existe verifica su contenido por si la tuviera
que actualizar: Restringe el acceso a recursos que no sean de la APP (en un entorno compartido),
basándose en la etiqueta APP_NAME
• Si no existiera, crea el Grupo ${APPID}-GAPP
• Si no existiera crea el Grupo ${APPID}-GAPP2
• Si no existiera crea el Role ${APPID}-RAPP y le crea la relación de confianza con el IDL
• Añade la Policy ${APPID}-PSBLOCKVPC al Grupo ${APPID}-GAPP y al Role ${APPID}-RAPP
• Añade la Policy ${APPID}-PSCNOIAM al Grupo ${APPID}-GAPP y al Role ${APPID}-RAPP
• Añade la Policy ${APPID}-PSRESOURCEGROUP al Grupo ${APPID}-GAPP y al Role ${APPID}-RAPP
• Añade la Policy ${APPID}-PMYAPP al Grupo ${APPID}-GAPP y al Role ${APPID}-RAPP
• Obtiene el nombre de los Buckets de Aplicación de Log y de Intercambio (según casuística)
• Se crea o actualiza la Policy ${APPID}-PSS3APPINT para permitir según casuística acceso a los
Buckets de Aplicación, de Intercambio y de Log. La añade al Grupo ${APPID}-GAPP y al Role
${APPID}-RAPP
• Si la cuenta es –dev y no existiera, crea la Policy ${ACCNAME}-PSS3OFIPRO
• Asocia la Policy ${ACCNAME}-PSS3OFIPRO al Role OrganizationAccountOpeOfiProRole

• Gestión del la Policy ${ACCNAME}-PSS3OPECIC para el equipo de CiC si la cuenta es de tipo -dev
• Crea / Actualiza / Elimina la Policy según sea necesario y su asociación o no al Role
OrganizationAccountOpeCiCRole
• Si el Equipo de Operación de la Aplicación es CiC añade permisos sobre la carpeta
• Si el Equipo de Operación de la Aplicación NO es CiC elimina permisos sobre la carpeta
• Gestión del la Policy ${ACCNAME}-PSS3OPEATOS para el equipo de Atos si la cuenta es de tipo -dev
• Crea / Actualiza / Elimina la Policy según sea necesario y su asociación o no al Role
OrganizationAccountOpeAtosRole
• Si el Equipo de Operación de la Aplicación es Atos añade permisos sobre la carpeta
• Si el Equipo de Operación de la Aplicación NO es Atos elimina permisos sobre la carpeta
• Si la cuenta es Estándar, pero no es de –dev, crea el CrossAccount con la cuenta en el Bucket de
Intercambio
• Se desasocian todas las Policies que ya no deban estar activas en: ${APPID}-GAPP, ${APPID}-GAPP2
y ${APPID}-RAPP

• Realiza el procesado de cada una de las Opciones recibidas en el 3º parámetro:
• PS: ParameterStore. Realiza las siguientes acciones:
• Si no existiera, crea la Policy ${APPID}-PPARAMETERSTORE
• Asocia la Policy con ${APPID}-GAPP2 y ${APPID}-RAPP
• KMS: KMS. Realiza las siguientes acciones:
• Si no existiera, crea la Policy ${APPID}-PKMS
• Localiza la Key de KMS (en vsgawssegauditaccount) para el entorno de la cuenta
• Identifica la Policy default
• Verifica si estuviera incluida la cuenta en la Policy. Si no estuviera la añade y
actualiza la Policy
• FULL: GRANTSFULL. Realiza las siguientes acciones:
• Si no existiera, crea la Policy ${APPID}-PSGRANTSFULL
• Asocia la Policy con ${APPID}-GAPP y ${APPID}-RAPP

• READONLY: Solo Lectura. Realiza las siguientes acciones:
• Si no existiera, crea la Policy ${APPID}-PSFULLRO1
• Si no existiera, crea la Policy ${APPID}-PSFULLRO2
• PSS: Start/Stop. Realiza las siguientes acciones:
• Si no existiera, crea la Policy ${APPID}-PSSTARTSTOP
• NOBILL: NoBilling. Realiza las siguientes acciones:
• Si no existiera, crea la Policy ${APPID}-PSNOBILLING
• NOSUPPORT: NoSupport. Realiza las siguientes acciones:
• Si no existiera, crea la Policy ${APPID}-PSNOSUPPORT
• NOIAMFULL: NoIAMFull. Realiza las siguientes acciones:
• Si no existiera, crea la Policy ${APPID}-PSNOIAMFULL

• Se desasocian las Policies Customizadas que ya no deban estar activas en: ${APPID}-GAPP2 y
${APPID}-RAPP
• Se asocian las Policies Customizadas que falten en: ${APPID}-GAPP2 y ${APPID}-RAPP
Gestión de la Seguridad. SecurityDelegada
Datos de entrada:
• Lista Opciones: PSS, FULL, READONLY, NOBILL, PS, KMS, NOSUPPORT, NOIAMFULL (la lista podrá
tener más de 1 opción, separada por “.”
• Lista de policies : Lista de Policies Customizadas separadas por “.”
Tareas que realiza:
• Si no existiera, crea la Policy ${APPID}-PSGRANTSFULL: Permisos Full Access.
• Si no existiera, crea la Policy ${APPID}-PSBLOCKVPC: Bloquea la modificación a nivel de VPC,
Subnet, etc.
• Si no existiera, crea la Policy ${APPID}-PSCNOIAM: Bloquea la modificación a nivel de IAM, sólo
admite consultas.
• Si no existiera, crea la Policy ${APPID}-PSNOBILLING: Bloquea el acceso al Billing

• Si no existiera crea el Role ${APPID}-RDeployAtlas y le crea la relación de confianza con la cuenta
vsgawsicaccount, donde está desplegada la aplicación Atlas
• Añade la Policy ${APPID}-PSBLOCKVPC al Role ${APPID}-RDeployAtlas
• Añade la Policy ${APPID}-PSCNOIAM al Role ${APPID}-RDeployAtlas
• Si no existiera, añade en el Grupo GDeployAtlas de la cuenta vsgawsicaccount la capacidad de
acceder a la cuenta con Switch Role
• Realiza el procesado de cada una de las Opciones recibidas en el 3º parámetro:
• PS: ParameterStore. Realiza las siguientes acciones:
• Si no existiera, crea la Policy ${APPID}-PPARAMETERSTORE
• Asocia la Policy con el Role ${APPID}-RDeployAtlas
• KMS: KMS. Realiza las siguientes acciones:
• Si no existiera, crea la Policy ${APPID}-PKMS
• Localiza la Key de KMS (en vsgawssegauditaccount) para el entorno de la cuenta
• Identifica la Policy default y verifica si estuviera incluida la cuenta en la Policy. Si no
estuviera la añade y actualiza la Policy

• FULL: GRANTSFULL. Realiza las siguientes acciones:
• Si no existiera, crea la Policy ${APPID}-PSGRANTSFULL
• NOBILL: NoBilling. Realiza las siguientes acciones:
• Si no existiera, crea la Policy ${APPID}-PSNOBILLING
• APPINT: Acceso a Bucket de Intercambio y/o Aplicación. Realiza las siguientes acciones:
• Localiza la Policy ${APPID}-PSS3APPINT
• Se asocian las Policies Customizadas que falten en el Role ${APPID}-RDeployAtlas
• Se desasocian las Policies Customizadas que ya no deban estar activas en el Role ${APPID}-
RDeployAtlas
Gestión de Grupos
Se dispone de varias funcionalidades para la Gestión de Grupos, aunque actualmente no tiene uso, ya
que no hay usuarios Locales (excepto programáticos):
• Lista los usuarios de la Cuenta que no estén asociados a ambos Grupos ${APPID}-GAPP y ${APPID}-
GAPP2
• Lista los usuarios de la Cuenta que estén asociados al Grupo ${APPID}-GAPP
• Lista los usuarios de la Cuenta que estén asociados al Grupo ${APPID}-GAPP2
• Añade un Usuario a ambos Grupos ${APPID}-GAPP y ${APPID}-GAPP2
• Elimina un Usuario del Grupo ${APPID}-GAPP
• Elimina un Usuario del Grupo ${APPID}-GAPP2
Creación de Usuarios SMTP
Los Usuarios SMTP se aprovisionan todos en la cuenta de Comunicaciones (vsgawscommsaccount).

Datos de entrada:
Tareas que realiza:
• Si no existiera, crea el usuario ${APPID}-USENDMAILS en la cuenta vsgawscommsaccount
• Si el usuario no tuviera Access Key, la Crea
• Obtiene el AccessKeyId y el SecretAccessKey
• El SMTPUsername será igual al AccessKeyId
• Obtiene el SMTPPassword al ejecutar el script aws-ses-smtp-password.sh pasándole como
parámetro el SecretAccessKey
• Si no existe, crea la Policy AmazonSesSendingAccess y la asocia al Usuario ${APPID}-
USENDMAILS
• Guarda en el ParameterStore de la cuenta vsgawscommsaccount los datos: User,
SMTPUsername y SMTPPassword
• Notifica las Credenciales por email a Gonzalo Gonzalez
Creación de Usuarios Programático S3
Los Usuarios programáticos S3 soportan varias opciones:

• Bucket de Aplicación o de Intercambio
• Permisos de Lectura/Escritura o sólo Lectura
• Customizar el nombre del Usuario
Datos de entrada:
• Permisos: RW (Lectura/Escritura) o RO (sólo Lectura)
• Tipo de Bucket: intercambio o aplicación
• Nombre de Usuario: Se utilizará ${APPID}-${NOMBRE}. Valor por defecto: ${APPID}-UDEVELOP
Tareas que realiza:
• Se obtiene el nombre del Bucket, según los datos proporcionados
• Se identifica la Policy a aplicar en base a los datos proporcionados
• Si no existiera, crea el usuario ${APPID}-${NOMBRE}
• Si el usuario no tuviera Access Key, la Crea
• Obtiene el AccessKeyId y el SecretAccessKey
Creación de Usuarios Programático S3

• Si no existe, crea la Policy . Será alguna de estas:
• ${APPID}-PSS3USERINT
• ${APPID}-PSS3USERINTRO
• ${APPID}-PSS3USERAPP
• ${APPID}-PSS3USERAPPRO
• la asocia la Policy creada al Usuario ${APPID}-${NOMBRE}
• Notifica las Credenciales por email a Gonzalo Gonzalez
Gestión del Cross Account S3
El Cross Account S3 se define a nivel de Bucket respecto a una cuenta distinta a la propietaria del
Bucket y se especifican los permisos concretos sobre los recursos que se indiquen.
En la implementación realizada, para crear permisos de Cross Account a nivel de S3 es necesario
conocer la cuenta propietaria del Bucket, el nombre del Bucket, la cuenta que quiere acceder al
Bucket, las carpeta sobre las que se concederán permisos y el conjunto de permisos:
• Lectura
• Escritura
• Borrado.
Se han implementado varias funcionalidades para la gestión del Cross Account S3:
• Listar Permisos: sólo los de la cuenta especificada
• Listar todos los Permisos: Los de todas las cuentas
• Añadir Cross Account
• Eliminar permisos de Cross Account de una Carpeta de la cuenta especificada
• Eliminar todos los permiso de Cross Account de la cuenta especificada. Los de las demás cuentas
se conservarán
Cross Account S3. Listar Permisos
Datos de entrada:
• ACC solicitante: Se ha de seleccionar alguna de las cuentas existentes
• ACC propietaria: Se ha de seleccionar alguna de las cuentas existentes distinta a la anterior
• Nombre del Bucket
Tareas que realiza:
• Se obtiene el ACCID de la cuenta solicitante
• Se localiza la Policy de Bucket y se analizan todos sus bloques, buscando “_Folder”
• Se intentan localizar permisos de Lectura para esa carpeta y cuenta solicitante
• Se intentan localizar permisos de Escritura para esa carpeta y cuenta solicitante
• Se intentan localizar permisos de Borrado para esa carpeta y cuenta solicitante
Cross Account S3. Listar todos los Permisos
Datos de entrada:
Tareas que realiza:
• Se genera el listado de todas las cuentas (de la Nueva Arquitectura y de la vieja Infra) identificando
ACC y ACCID
• Se localiza la Policy de Bucket y se buscan todas las cuentas que tienen permiso actualmente
• Por cada cuenta con permisos se localiza su nombre en el listado generado inicialmente
• se analizan todos sus bloques, buscando “_Folder”
• Se intentan localizar permisos de Lectura para esa carpeta y cuenta localizada
• Se intentan localizar permisos de Escritura para esa carpeta y cuenta localizada
• Se intentan localizar permisos de Borrado para esa carpeta y cuenta localizada
Cross Account S3. Añadir Cross Account
Datos de entrada:
• Carpeta
• Lista de Permisos: R, W, D separados por “.”
Tareas que realiza:
• Se Busca la Policy de Bucket
• Si no existe se crea la Policy ajustando los permisos especificados
• Si ya existe Policy del Bucket se genera un fichero por cada Statement.
• Si no estuviera la cuenta solicitante en el Bloque 0, la añade y regenera el fichero
• Se recorren todos los ficheros de tipo “UndeleteFolder” (Bloque 1)
• Si trata la Carpeta indicada se mira a ver si ya estuviera la cuenta
• Si no está tratada la cuenta solicitante, añade la cuenta y regenera el fichero
Cross Account S3. Añadir Cross Account

• Se recorre la lista de permisos recibida y se tratan los que apliquen (R / W / D)
• Si aplica, se recorren todos los ficheros de tipo “R_Folder” (Bloque 2)
• Si no está tratada la cuenta solicitante, añade la cuenta y regenera el
fichero
• Si aplica, se recorren todos los ficheros de tipo “W_Folder” (Bloque 3)
fichero
• Si aplica, se recorren todos los ficheros de tipo “D_Folder” (Bloque 4)
fichero
• Se regenera el fichero de Policy de Bucket a partir de los ficheros de los Statements
• Actualiza la Policy con el fichero regenerado
Cross Account S3. Eliminar permisos de Cross Account de una Carpeta
Datos de entrada:
• Carpeta
• Lista de Permisos: R, W, D separados por “.”
Tareas que realiza:
• Se genera un fichero por cada Statement.
• Se recorre la lista de permisos recibida y se tratan los que apliquen (R / W / D)
• Si aplica, se recorren todos los ficheros de tipo “R_Folder” (Bloque 2)
• Si está la cuenta solicitante, regenera el fichero eliminando la cuenta
• Si fuera la única cuenta existente en el fichero, elimina el fichero
Cross Account S3. Eliminar permisos de Cross Account de una Carpeta

• Si aplica, se recorren todos los ficheros de tipo “W_Folder” (Bloque 3)
• Si aplica, se recorren todos los ficheros de tipo “D_Folder” (Bloque 4)
• Se regenera el fichero de Policy de Bucket a partir de los ficheros de los Statements
Cross Account S3. Eliminar todos los permisos de una cuenta
Datos de entrada:
Tareas que realiza:
• Se genera un fichero por cada Statement.
• Si estuviera la cuenta solicitante en el Bloque 0, regenera el fichero eliminando la cuenta
• Se recorre todos los ficheros excepto el del Bloque 0
• Si estuviera la cuenta solicitante en el fichero, regenera el fichero eliminando la cuenta
• Si queda algún fichero, se regenera el fichero de Policy de Bucket a partir de los ficheros de
los Statements
• Si no queda ningún fichero, elimina la Policy existente
Gestión de VPCs Endpoints
Se han implementado varias funcionalidades para la gestión de VPC Endpoints:

• Listar VPC Endpoints Instalados: sólo los de la cuenta especificada y APP especificada
• Listar VPC Endpoints Disponibles: Los de tipo Interface
• Añadir VPC Endpoint
• Eliminar VPC Endpoint existente
Gestión de VPCs Endpoints. Listar VPC Endpoints Instalados
Datos de entrada:
Tareas que realiza:
• Obtiene el VPCID de la Aplicación
• Obtiene la lista de VPC Endpoint existentes en la cuenta
• Recorre la lista, verificando si el VPCID del VPC Endpoint coincidiera con el de la cuenta.
• Verifica que el VPC Endpoint sea de tipo Interface
• Comprueba que su estado sea “available” o “pending”
• Recorre las Subnets utilizadas
• Identifica la etiqueta APP_NAME de la Subnet
• Localiza la APP asociada a dicha VPC y APP_NAME
• Si el valor obtenido coincide con la APP recibida por parámetro se recupera la
siguiente información y la devuelve en una línea separados los campos por “:”
VpcEndpointId:ServiceName:DnsName:State
Gestión de VPCs Endpoints. Listar VPC Endpoints Disponibles
Datos de entrada:
Tareas que realiza:
• Obtiene la lista de VPC Endpoint disponibles para la cuenta que sean de tipo Interface
Gestión de VPCs Endpoints. Añadir VPC Endpoint
Datos de entrada:
• VPC Endpoint: ServiceName
Tareas que realiza:
• Obtiene el nombre del Endpoint
• Obtiene el VPCID y el APP_NAME de la Aplicación
• Recorre las Subnets de la Cuenta
• Comprueba si coincide su APP_NAME con el de la Aplicación
• Genera lista de las Subnets que sean de Backend
• Recorre los Security Groups de la Cuenta
• Comprueba si están asociados a la VPC. Mirando el VPCID
• Comprueba si coincide su APP_NAME con el de la Aplicación
• Genera lista de los Security Groups si su Description es “BACKEND” o “INTRA-VPC”
• Crea el VPC Endpoint para la VPCID con la lista de Subnets y la lista de Security Groups
Gestión de VPCs Endpoints. Eliminar VPC Endpoint
Datos de entrada:
• VPC Endpoint ID
Tareas que realiza:
• Elimina el VPC Endpoint especificado
• Consulta periódicamente hasta que su estado deje de ser “available”
Gestión de Encendidos y Apagados
Esta funcionalidad se limita a Crear / Modificar / Eliminar ficheros de definición de los Encendidos y
Apagados.
Los tipos de objetos que se tratan aquí son Instancias EC2, Instancias RDS y ASG
Los encendidos y apagados se realizan con 2 tareas planificadas:
• GestionOnOff.sh, que se ejecuta cada minuto para verificar si a esa hora exacta se tuviera que
iniciar el apagado o encendido de algún recurso. Lo añade a una cola
• ProcesaOnOff.sh, es un demonio planificado cada hora (por si muriese), que se encarga de realizar
el encendido o Apagado y de esperar a que el estado sea el correcto
Se han implementado varias funcionalidades para la gestión de Encendidos y Apagados:
• Obtener listado de Items: Obtiene todas las reglas actualmente definidas para un determinado
criterio
• Añadir Regla: Añade regla de On/Off
• Modificar Regla: Modifica regla de On/Off existente
• Eliminar Regla: Elimina regla de On/Off
Gestión de Encendidos y Apagados. Obtener listado de Items
Los ficheros de Reglas tienen los siguientes campos separados por “:”
Minuto:Hora:diaMes:Mes:diaSemana:Estado:TipoItem:ACC:APP:Id:TMax
Datos de entrada:
• Tipo de Item: Los valores aceptados son “Instancia”, “RDS” y “ASG”
• Estado: Los valores aceptados son “on”, “off” y “todos”
Tareas que realiza:
• Recorre todos los ficheros de definición de Reglas de OnOff en la ruta /var/www/onoff
• Verifica que el fichero tratado tenga alguna regla para la ACC y APP y que coincida con los
criterios de búsqueda de Tipo de Item y Estado.
• Confirma que el fichero se corresponda con el de la APP
• En caso contrario notifica Error
• Obtiene todas las Reglas que se ajusten al criterio de búsqueda
• En caso de Recursos nominales ≠ “*”, obtiene el nombre del recurso
• Devuelve lista de reglas que se ajusten al criterio de búsqueda. Incluyen un último
campo adicional que es el nombre del recurso (cuando aplica)
Gestión de Encendidos y Apagados. Añadir Regla
Datos de entrada:
• Rule: Regla a añadir
Tareas que realiza:
• Define el nombre del fichero de Reglas de la APP: /var/www/onoff/${ACC}.${APP}.cfg
• Si ya existiera un fichero de Reglas de OnOff para esta APP, lo versiona con la FechaHora
• Añade la nueva Regla al fichero de Reglas de la APP y lo ordena.
Gestión de Encendidos y Apagados. Modificar Regla
Datos de entrada:
• Rule: Regla actual a modificar
• New Rule: Nueva definición de la regla
Tareas que realiza:
• Elimina la regla existente recibida por parámetros.
• Añade la nueva Regla al fichero de Reglas de la APP y lo ordena.
Gestión de Encendidos y Apagados. Eliminar Regla
Datos de entrada:
• Rule: Regla a eliminar
Tareas que realiza:
• Elimina la regla existente del fichero de Reglas y lo ordena.
Gestión de Backups
En la ejecución de la Capa0 se crea:

• El Vault de la APP
• Los 2 Planes de Backup de la APP (el genérico y el de RDS)
• Una regla de Backup con el mismo nombre del Plan
• Una selección de Recursos con el mismo nombre del Plan, basado en la etiqueta Backup.
Esta funcionalidad permite ajustar las reglas de Backup existentes, así como añadir reglas nuevas o
eliminar reglas
La selección de Recursos NO se trata y no de debe tratar. Se mantiene la definición que se hizo en
Capa0
Se han implementado varias funcionalidades para la gestión de Backups:

• Leer Regla: Obtiene la configuración actual de las reglas de Backup de un Plan de Backup
• Añadir Regla: Añade regla de Backup
• Modificar Regla: Modifica regla de Backup existente
• Eliminar Regla: Elimina regla de Backup
Gestión de Backups. Leer Regla
Esta funcionalidad se limita a recuperar la configuración actual de todas las reglas de Backup de un
determinado Plan de Backup
Datos de entrada:
• Plan de Backup: Nombre del Plan
Tareas que realiza:
• Verifica que exista el Vault de la APP
• Recorre todos los Planes de Backup de la Cuenta hasta localizar al Plan de Backup especificado
• Obtiene el ID, para recuperar su configuración
• Recorre todas las reglas de Backup definidas en el Plan de Backup
• Devuelve un registro por cada Regla que contiene los siguientes campos separados por “:”
RuleName:ScheduleExpression:RetrasoMaximo:DuracionMaxima:Retencion:DiasParaAlmacFrio
Gestión de Backups. Añadir Regla
Esta funcionalidad añade una regla de Backup a un determinado Plan de Backup

Datos de entrada:
• Definición de la regla: Debe estar compuesta por un registro de 6 campos separados por “:”
Tareas que realiza:
• Verifica que no exista ya una regla con el nombre del 1º campo de la Definición
• Genera la configuración inicial del Plan en formato JSON
• Añade a la configuración la definición de la nueva regla
• Actualiza el Plan de Backup
Gestión de Backups. Modificar Regla
Esta funcionalidad modifica una regla de Backup de un determinado Plan de Backup

Datos de entrada:
• Definición de la nueva regla: Debe estar compuesta por un registro de 6 campos separados por “:”
• Nº de regla a modificar: Debe ser un número que especifica cual de las reglas actualizar (0 a n-1)
Tareas que realiza:
• Cuando llega a la Regla a actualizar, utiliza los datos recibidos
Gestión de Backups. Eliminar Regla
Esta funcionalidad elimina una regla de Backup de un determinado Plan de Backup

Datos de entrada:
• Nº de regla a eliminar: Debe ser un número que especifica cual de las reglas eliminar (0 a n-1)
Tareas que realiza:
• Cuando llega a la Regla a eliminar omite sus datos
Recuperación de Backups
La recuperación de Backup se basa en los Snapshots que realiza AWS Backup junto con los Metadatos
que se generan diariamente para hacer viable dicha recuperación. Los scripts que generan esos
Metadatos son InfoInstancias.sh e InfoRDS.sh, que se ejecutan diariamente a las 0:05 y 0:10 UTC.
Los Metadatos consiste el la información que existe en cada cuenta de todas las Instancias y de sus
Volúmenes, así como de todas las Instancias de RDS, de sus TAGs y de los Clusters de RDS.
La implementación realizada a nivel de EC2 permite recuperar Volumen, Imagen o Servidor

Se han desarrollado varias funcionalidades para la Recuperación de Backups:
• Listar Snapshot: Obtiene la lista de fechas en las que existe Snapshots para una APP
• Listar Instancias Fecha: Obtiene la lista de Instancias de las que hay Snapshot para una fecha
• Listar Volúmenes: Obtiene la lista de Volúmenes que se podrían recuperar de una determinada
Instancia y fecha
• Listar Snapshot Fecha: Obtiene la lista de TimeStamp en las que hay Snapshots para una Instancia
• Recuperar Volumen: Recupera un Volumen de manera aislada
• Recuperar Imagen: Recupera una Imagen (AMI)
• Recuperar Servidor: Recupera un Servidor
Recuperación de Backups. Listar Snapshot
Esta funcionalidad obtiene la lista de fechas en las que existe Snapshots para una Aplicación. Sirve
para ir refinando la búsqueda
Datos de entrada:
Tareas que realiza:
• Obtiene el ACCID de la Cuenta
• Obtiene el listado de todos los Snapshot de la Cuenta
• Recorre todos los Snapshots y filtra aquellos que pertenezcan a la APP especificada.
• Recupera la fecha del Snapshot
• Devuelve la lista de fechas sin duplicados en orden descendente con formato YYYY-MM-DD
Recuperación de Backups. Listar Instancias Fecha
Esta funcionalidad obtiene la lista de Instancias con su InstanceId en las que existen Metadatos para
una determinada fecha. Sirve para ir refinando la búsqueda
Datos de entrada:
• Fecha: En formato YYYY-MM-DD
Tareas que realiza:
• Obtiene el APP_NAME y la VPVID de la APP especificada
• Recorre el fichero de Metadatos de Instancias de la Cuenta y fecha especificada revisando la
información de cada Instancia
• Verifica si coincide el APP_NAME de la Instancia
• Verifica si coincide el VPCID
• Devuelve el Nombre e InstanceId
• Ordena los datos eliminando duplicados
Recuperación de Backups. Listar Volúmenes
Esta funcionalidad obtiene la lista de Volúmenes que se podrían recuperar de una determinada
Instancia y fecha. Sirve para ir refinando la búsqueda en el caso de querer Restaurar Volumen
Datos de entrada:
• InstanceId: Id de Instancia de la que listar los Volúmenes disponibles
Tareas que realiza:
• Recorre el fichero de Metadatos de Volúmenes de la Cuenta y fecha especificada revisando la
información de cada Volumen
• Verifica si la Instancia a la que estuviera atachado el Volumen coincide con la especificada
• Verifica que el estado del Volumen sea “in-use”
• Recupera el Nombre, el VolumeId y el Device
• Ordena los datos eliminando duplicados
Recuperación de Backups. Listar Snapshot Fecha
Esta funcionalidad obtiene la lista de TimeStamp en las que hay Snapshots para una Instancia. Sirve
para refinar la búsqueda
Datos de entrada:
• InstanceId: Id de Instancia de la que listar los Volúmenes disponibles
Tareas que realiza:
• Recorre el fichero de Metadatos de Instancias de la Cuenta y fecha especificada revisando la
información de cada Instancia
• Verifica si el InstanceId coincide con el especificado
• Obtiene el RootDeviceName
• Localiza el Volumen atachado que coincida con el RootDeviceName
• Recupera el VolumeId
• Recorre la lista de Snapshot existente para la Cuenta y fecha y con el VolumeId
• Recupera el StartTime (que es un TimeStamp) de los Snapshot existentes
Recuperación de Backups. Recuperar Volumen
Esta funcionalidad recupera un Volumen a partir de un Snapshot determinado

Datos de entrada:
• VolumeId : Id del Volumen (obtenido de la información de Snapshot)
• TimeStamp : StartTime del Snapshot
Tareas que realiza:
• Recorre el fichero de Metadatos de Volúmenes de la Cuenta y fecha especificada buscando el que
coincida con el VolumeId
• Busca las etiquetas del Volumen para recuperar el Name
• Recupera los datos: AvailabilityZone, Encrypted, VolumeType e Iops
• Recorre la lista de Snapshot existente para la Cuenta y fecha y que el VolumeId coincida
• Crea el Volumen a partir de Snapshot, añadiendo al nombre original .Recovery.${FECHA}
• ${FECHA} es la FechaHora del momento de la recuperación
Recuperación de Backups. Recuperar Imagen
Esta funcionalidad genera una Imagen a partir de los Snapshot que pertenecían a una Instancia en un
TimeStamp determinado
Datos de entrada:
• InstanceId : Id de la Instancia
• TimeStamp : StartTime del Snapshot del Volumen principal
Tareas que realiza:
• Recorre el fichero de Metadatos de Instancias de la Cuenta y fecha especificada buscando el que
coincida con el InstanceId
• Busca las etiquetas de la Instancia para recuperar el Name
• Recupera los datos: Architecture, RootDeviceName, VirtualizationType y nº de Volúmenes
• Realiza un filtrado de los Snapshots que se ajustan a la fecha
• Recorre el fichero de Metadatos de Volúmenes de la Cuenta y fecha especificada, buscando todos
los que estuvieran atachados a la InstanceId
• Recupera los datos: VolumeId, Device, VolumeType, Iops, Size, Encrypted,
DeleteOnTermination y AvailabilityZone
Recuperación de Backups. Recuperar Imagen

• Localiza en los Snapshot pre filtrados el que su VolumeId coincida con el VolumeId
recuperado de los Metadatos
• Obtiene el VolumeId y el State del Snapshot
• Verifica que el State sea “completed”
• Recupera el SnapshotId
• Recupera el StartTime del Snapshot
• Calcula la fecha y hora del Snapshot
• Calcula la diferencia de tiempo entre el StartTime del Snapshot y el TimeStamp
recibido como parámetro
• Comprueba que la diferencia de tiempo sea inferior a 600 segundos
• Verifica si el Volumen tratado es el principal
• Si se han recuperado el volumen principal y todos los demás volúmenes se crea la Imagen, con el
nombre de la Instancia + .Recover.${FECHA}
Recuperación de Backups. Recuperar Servidor
Esta funcionalidad genera una Servidor a partir de los Snapshot que pertenecían a una Instancia en
un TimeStamp determinado
Datos de entrada:
• InstanceId : Id de la Instancia
• TimeStamp : StartTime del Snapshot del Volumen principal
Tareas que realiza:
• Recorre el fichero de Metadatos de Instancias de la Cuenta y fecha especificada buscando el que
coincida con el InstanceId
• Busca las etiquetas de la Instancia para recuperar el Name
• Recupera los datos: Architecture, RootDeviceName, VirtualizationType, InstanceType,
KeyName, SubnetId, la lista de Security Groups y nº de Volúmenes
• Realiza un filtrado de los Snapshots que se ajustan a la fecha
• Recorre el fichero de Metadatos de Volúmenes de la Cuenta y fecha especificada, buscando todos
los que estuvieran atachados a la InstanceId

• Recupera los datos: VolumeId, Device, VolumeType, Iops, Size, Encrypted,
DeleteOnTermination y AvailabilityZone
• Localiza en los Snapshot pre filtrados el que su VolumeId coincida con el VolumeId
recuperado de los Metadatos
• Obtiene el VolumeId y el State del Snapshot
• Verifica que el State sea “completed”
• Recupera el SnapshotId
• Recupera el StartTime del Snapshot
• Calcula la fecha y hora del Snapshot
• Calcula la diferencia de tiempo entre el StartTime del Snapshot y el TimeStamp
recibido como parámetro
• Comprueba que la diferencia de tiempo sea inferior a 600 segundos
• Verifica si el Volumen tratado es el principal
• Si se han recuperado el volumen principal y todos los demás volúmenes se crea una Imagen, con el
nombre de la Instancia + .Recover.${FECHA}

• Añade etiqueta Name a la Imagen
• Crea la Instancia nueva con los datos recuperados de los Metadatos
• Desregistra la Imagen anterior
• Una vez levantado el servidor busca de nuevo en los Metadatos de los Volúmenes, recorriéndolos
todos los del servidor
• Lee cada una de las etiquetas de los volúmenes
• Asigna las mismas etiquetas a los volúmenes creados en el nuevo Servidor
Servidor Automatización
vsgawsicaccount AWS Ireland (eu-west-1)
AOPE005PRO-VPC (10.112.1.64/26)
AOPE005PRO-FSUB01a AOPE005PRO-FSUB01b
10.112.1.64/28 10.112.1.80/28
AOPE005PRO-
ELBAUT
AOPE005PRO-BSUB01a AOPE005PRO-BSUB01b
10.112.1.96/28 10.112.1.112/28
m5.large
AOPE005PBLAUT01
10.112.1.120
zona 1a zona 1b
Servidor Automatización
• Toda la operativa de automatización se realiza en la cuenta vsgawsicaccount, desde el servidor
de Automatización AOPE005PBLAUT01 (10.112.1.120).
• Este servidor utiliza la KeyPair: AOPE005PRO-KEY vsgawsicaccount AWS Ireland (eu-west-1)
• Se trata de una instancia ec2 Amazon Linux 1 con apache y php. AOPE005PRO-VPC (10.112.1.64/26)
AOPE005PRO-FSUB01a
10.112.1.64/28
AOPE005PRO-FSUB01b
10.112.1.80/28
• El servidor tiene un único volumen de EBS de 8 GiB de tipo gp2

• El servidor es accesible a través del balanceador AOPE005PRO-ELBAUT, que es de tipo
AOPE005PRO-
ELBAUT
AOPE005PRO-BSUB01a AOPE005PRO-BSUB01b
10.112.1.96/28 10.112.1.112/28
internal-face, por lo que sólo es accesible desde la red de Viesgo

• DNS: internal-AOPE005PRO-ELBAUT-1254729770.eu-west-1.elb.amazonaws.com.
m5.large
AOPE005PBLAUT01
10.112.1.120
zona 1a zona 1b
• CNAME atlas-ope.Cloud.Viesgo.com que apunta al balanceador.

• El balanceador dispone de 2 Listener:
• Tráfico HTTP 80: redirecciona a HTTPS
• Tráfico HTTPS 443: utiliza el certificado *.cloud.viesgo.com y envía al Target Group
AOPE005PRO-TGAUT
• El Target Group AOPE005PRO-TGAUT envía el tráfico recibido por el puerto 80 de la instancia
AOPE005PBLAUT01
• El servidor EC2 AOPE005PBLAUT01 tiene definido el Tag NAT_PROFILE con el valor ALTO, para
permitir la navegación web.
Configuración Servidor Automatización
El servidor dispone de los siguientes usuarios (además de root):
• ec2-user: es el usuario de acceso. Generalmente sólo se utiliza como puerta de entrada.
• apache: es el usuario de Apache. Por defecto debe estar configurado sin login, pero cuando se
debe configurar algo en el servidor, realizar versionado del SW, ejecutar algún script o lanzar
comandos AWS, es necesario quitarle el nologin y definirle la Shell.
• A continuación se muestra la información del usuario apache en el fichero passwd
#apache:x:48:48:Apache:/var/www:/sbin/nologin
apache:x:48:48:Apache:/var/www:/bin/bash
La herramienta se utiliza para Automatizar operativa AWS. Al ser una herramienta Web sobre
Apache, el usuario que realiza todas las acciones es apache, por ello todas las configuraciones se
deben realizar sobe el usuario apache.
• El home del usuario apache está definido en /var/www, pero es propiedad de root
• El DocumentRoot del servidor Web es /var/www/html, por lo tanto, sólo será
visible/accesible a través del servidor Web lo que cuelgue de /var/www/html
Configuración AWS
La configuración de AWS se realiza en el usuario apache.
En la ruta /var/www/.aws se encuentran los ficheros
• config: Se definen los profiles asociados a cada una de las cuentas junto al Role que se utiliza
• credentials: Se definen las credenciales utilizadas (Access key y Secret key)
• Para el acceso a la nueva Arquitectura se utiliza el usuario ARQ_ORG de la cuenta
vsgawsrootaccount. Lleva asociado el profile VIESGO_NA
• Para el acceso a las cuentas de la vieja Infra se utiliza el usuario ARQ_ORG de la cuenta
viesgorootaccount. Lleva asociado el profile default
Accesos al Servidor Automatización
El servidor es accesible a través de ThinLinc de 3 modos:
• Servidor Web (herramienta de Automatización): Inicio > OPERACIONES > EAWS >
HERRAMIENTAS > ATLAS > PRO
• Acceso a la máquina Linux en modo ssh con el usuario ec2-user: Inicio > OPERACIONES >
EAWS > CONSOLAS > AUTOMATIZACIÓN
• Acceso a la máquina Linux en modo sftp con el usuario ec2-user: Inicio > OPERACIONES >
EAWS > CONSOLAS > AUTOMATIZACION-SFTP
Servidor Automatización. Carpetas
Revisaremos las carpetas del usuario apache, que es con el que se sirve la Herramienta de
Automatización:
• /var/www: Home del usuario apache
• /var/www/html: DocumentRoot. Aquí reside la página principal que da acceso a Atlas,
Comunicaciones y a la Herramienta
• /var/www/html/nuevaARQ: La herramienta está desplegada aquí
• /var/www/html/Comunicaciones: La herramienta de Comunicaciones para gestión de los
Security Groups INTRA-VPC está desplegada aquí
• /var/www/html/Atlas: La página html para acceder a los recursos de Atlas está desplegada
aquí
• /var/www/html/images: contiene imágenes utilizadas en la Herramienta, como el Logo.
• /var/www/tmp: Carpeta para generación de ficheros temporales.
• /var/www/email: Carpeta auxiliar para envío de emails. Ya sin apenas uso.
• /var/www/filtros: Carpeta auxiliar que utiliza la herramienta de Comunicaciones.
• /var/www/logs: Se vuelcan aquí los Logs de algunas funcionalidades, como la de Capa0.
• /var/www/data: Contiene los ficheros VPCs.txt y TAPPs.txt y todas sus versiones.
• /var/www/onoff: Contiene los ficheros de configuración de las planificaciones de encendidos
y apagados.
Servidor Automatización. Carpetas
• /var/www/onoff/dependencias: Actualmente no está en uso.
• /var/www/onoff/Estados: contiene ficheros json de los recursos de cada cuenta, que se
generan cuando se está realizando encendidos o apagados, para controlar si está completada
la acción.
• /var/www/onoff/logs: Se genera un fichero diario con la actividad de ese día.
• /var/www/onoff/DesiredState: Contiene un fichero por cada tipo de recurso (Instancias, RDS
y ASG) que gestiona el encolado de recursos a tratar.
• /var/www/inventario: Se genera un fichero cada hora que contiene todos los recursos de tipo
Instancia, RDS y ASG. Permite identificar todos los recursos de un determinado tipo que
pertenecen a una aplicación, para poder planificar el apagado o encendido de esos recursos
sin tener que especificar cada uno de ellos.
• La Utilidad de onoff, consulta estos ficheros para identificar los recursos a encender o
apagar.
• / var/www/inventario/InfoInstancias : Se genera un fichero diario con el detalle de las
Instancias de cada cuenta y de sus volúmenes. Se utilizan en caso de restaurar Backup
• / var/www/inventario/InfoRDSs : Se genera un fichero diario con el detalle de las Instancias
RDS, de sus Tags, de los Clusters de cada cuenta. Se utilizan en caso de restaurar Backup

Viesgo DevOps Devolucion S1 Arquitectura - v1.2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Viesgo DevOps Devolucion S1 Arquitectura - v1.2

Cargado por

Copyright:

Formatos disponibles

DevOps VIESGO

10.112.64.0/18 Distribución DEV

10.112.128.0/18 Distribución PRE

10.112.192.0/18 Distribución PRO

10.113.0.0/19 VProducción DEV 10.113.32.0/19 VProducción PRE

10.113.64.0/19 VProducción PRO 10.113.96.0/19 Corporativo DEV

10.113.128.0/19 Corporativo PRE 10.113.160.0/19 Corporativo PRO

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Para la gestión del Direccionamiento la Herramienta de Automatización utiliza un fichero, que

• Modalidad : Tipo de capa 0 (FULL | BI | OB)

Consultas. Esta información se obtiene del fichero VPCs.txt:

Campos del fichero VPCs.txt

Tareas que realiza (continuación):

Tiene doble funcionalidad:

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tiene doble funcionalidad:

En uno de los evolutivos de la Herramienta surgió la necesidad de desplegar Capa0 para

Las Políticas Customizadas que se pueden gestionar están clasificadas en 3 tipos:

Desde esta Utilidad se gestiona de manera independiente la Seguridad Local y la Seguridad

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Los Usuarios SMTP se aprovisionan todos en la cuenta de Comunicaciones (vsgawscommsaccount).

Los Usuarios programáticos S3 soportan varias opciones:

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Se han implementado varias funcionalidades para la gestión de VPC Endpoints:

En la ejecución de la Capa0 se crea:

Se han implementado varias funcionalidades para la gestión de Backups:

Esta funcionalidad añade una regla de Backup a un determinado Plan de Backup

Esta funcionalidad modifica una regla de Backup de un determinado Plan de Backup

Esta funcionalidad elimina una regla de Backup de un determinado Plan de Backup

La implementación realizada a nivel de EC2 permite recuperar Volumen, Imagen o Servidor

Esta funcionalidad recupera un Volumen a partir de un Snapshot determinado

Tareas que realiza (continuación):

Tareas que realiza (continuación):

Tareas que realiza (continuación):

• El servidor tiene un único volumen de EBS de 8 GiB de tipo gp2

internal-face, por lo que sólo es accesible desde la red de Viesgo

• CNAME atlas-ope.Cloud.Viesgo.com que apunta al balanceador.

También podría gustarte