#14 #15 Ni mas, ni menos.
Si, gracias a dios lo documenté todo. Es decir, me dediqué a realizar un tutorial como si supiera que hacía! Y iba borrandolo y reescribiendolo todo el rato! xD
Un puto suplicio. Pero es cierto que ahora ya lo haría mas rapido.
Si pues tags, las primeras veces... y luego como dices, le dieron por el culo! xD
Claro, la cosa va tal que así:
- Empece con un stack precreado de Cloudformation, que hacía un deployment de un bucket S3, con cloudfront y con un cert SSL desde ACM.
Nada. Lo desplegue infinitas veces, y en todas falló en algun punto. No habia manera. Rollback y volver a empezar, Y ir borrando a mano los buckets, etc...
Por lo que al final la cosa queda tal que:
- Gestor de DNS fuera del Route53 para TLD principal.
- Creo en Route53 un hosted zone para el subdominio, y en el gestor de Arsys, delego mediante los 4 registros NS de turno con los servers de Amazon.
- Luego creo el bucket. Lo hice publico desbloqueando, y luego añadiendo la policy correcta y el ACL pertinente (que no encontré como escribirlo via XML con los <grants> y tuve que hacerlo seleccionando en el bucket el Public Acces y dando permiso de "listar" (que es READ).... ojo con las traducciones al español de AWS macho...
- Lo siguiente, cloudfront para ALL EDGES contra el bucket (que previamente estaba ya habilitado para static web pages), con redirect de http a https i con certificado personalizado.
- Para el certificado, se crea normalmente, se añade la entrada en Route53 y a correr. Ya queda validado el dominio (el subdominio) y por lo tanto te lo EMITEN.
- Se puede ya asociar al cloudfront. Además, es importante marcar el DEFAULT ROOT OBJECT en cloudfront porque sino, cuando accedes via https, te salta el directorylist en XML...
- Una vez creado y deployed, en Route53, hay que crear un par de entradas A y AAAA para ip4 y ip6 que redirigan como ALIAS al servicio de cloudfront el subdominio. Y con esto ya se corre mas o menos.
Luego viene la puta locura del IAM. Crear un usuario para trabajar que esto es lo que mas me costó, porque no habia manera de que cuadraran las cosas.
Añadi en el bucket, una politica de s3:Listbucket para el usuario y un s3:* para las acciones del usuario en bucket/*
porqure si añadia las individuales clasicas put, get y delete, no funcionaba... :\
Luego en el usuario, una policy directa homologa de listbucket para el que toca, y de s3:* para las acciones contra el bucket/*. Y con esto ya pude currar.
La sorpresa final fue con WinSCP, que no habia manera de conectar. Y esas son 2 cosas curiosas:
1) El usuario tiene solamente politica de acceso al Bucket. Nada mas. En cambio, puede loguear en la consola con id (12 numeros IAM) y hacer muchas cosas! Otras estan capadas, pero en otras puede acceder! Y cuando va al s3, y deberian listarse los buckets (o al menos, solamente el suyo que tiene acceso) aparece PERMISION DENIED! Joedete! Asi que si quiera que alguien se loguee en la consola de AWS con este IAM espcifico creado para trabajar con el bucket (a efectos practicos, un usuario FTP lo llamariamos), no puede. No ve su bucket siquiera...
2) Y en WinSCP no habia manera, hasta que di con un tuto de un pavo en inet, que decia: en advanced conection, vete a Directories i pon entre "/" el nombre de tu bucket!
Entonces te queda tal que /nombre_del_bucket/, y con eso CONECTA!!!
Jodete patrón...
Alguna idea de como hacer para ver el bucket en la consola de S3?
