Resulta que una de las herramientas populares de código abierto tenía una configuración predeterminada para almacenar sus copias de seguridad en S3. Y, como marcador de posición para un nombre de bucket, usaron... el mismo nombre que yo usé para mi bucket. Esto significaba que cada despliegue de esta herramienta con valores de configuración por defecto intentaba almacenar sus copias de seguridad en mi bucket de S3. Así que, una horda de sistemas mal configurados está intentando almacenar sus datos en mi bucket privado de S3.
Comentarios
Yo prefiero los buckets con slots que estén delayed, porque si no, en tiempo real se me stuck en la tobera.
#1 Vigila la trócola, nunca ase sabe
Yo prefiero configurarle la mis cubos para que usen el almacenamiento en las tapiporlas locales para no necesitar usar la tobera por el problema que comenta #1, pero luego se desincroniza la trócola, como comenta #4.
Brutal.
Estoy en un proyecto donde gran parte es OpenSource. Incluimos un docker con un postgresql para evaluación. Sin ninguna seguridad y con unos mensajes inmensos por toda la documentación advirtiendo que la de use en producción sin configurar usuarios, redes, backups, etc.
No os podéis imaginar la cantidad de colgados que usan eso así...postres:postres y abierto al mundo.
Creo que de los principales fallos de diseño en AWS es que los nombres de los buckets sean globales...
Si hubiera que especificar el account id (como ocurre con el resto de recursos en AWS). Acabaríamos con muchos de estos problemas.
Si quieres regular el pipe, baja el fuste a 10 y activa el nepecode.
¡Equilicuá!
Pay wall...