GCS Reverse Proxy
1.0.0
Un proxy inverso de Google Cloud Storage. Para alojar sitios estáticos privados que usan objetos privados de almacenamiento en la nube de Google.
Desea servir sitios estáticos que usen sus cubos GCS, pero desea restringir el acceso a ellos.
Este servicio de micro proxy inverso se comportará como un servidor HTTP simple para una variedad de cubos GCS. Luego puede usar cualquier método apropiado para restringir el acceso a él. Por ejemplo, ponerlo detrás de Nginx, Caddy o una VPN.
Acceder a los objetos GCS privados a través del navegador requiere tokens especiales que estén codificados en la URL. Esto romperá la mayoría (si no todos) los sitios estáticos, ya que no pueden generar estos tokens o predecir el URI de cualquier activo que solicite o enlaces. Sin embargo, hacer un objeto de almacenamiento público significa que no hay forma de restringir el acceso a él.
Este proxy inverso servirá a un objeto privado sobre HTTP en el esperado (relativo), URI y no restringirá el acceso a estos objetos en absoluto. Sin embargo, al colocar este servidor detrás de otro proxy inverso, como NGINX o ponerlo en una VPN, podrá controlar el acceso de una manera que mejor se adapte a sus necesidades.
NB (si tiene el SDK GCLOUD instalado, ejecute
gcloud infoen su shell para verificar que haya iniciado sesión y tenga la identificación correcta del proyecto).
El Var de envía TARGET_BUCKETS espera una lista de cubos separada por coma, por ejemplo:
TARGET_BUCKETS='bucket-one,bucket-two'
El servidor lanzará a menos que se definan uno o más Target_Buckets.
Setting the HISTORY env var to true will start the server in history mode, for better SPA support. Responderá con el archivo Buckets root index.html para cualquier ruta que no tenga una extensión de archivo.
npm install
TARGET_BUCKETS="bucket-name" npm start
Una vez que el servidor esté en funcionamiento, para acceder a un objeto privado en un cubo debe hacer una solicitud de obtener:
<proxy-host>:<proxy-port>/<bucket-name>/<file-path>
Si la ruta del archivo existe en el cubo, y el servidor tiene la premisión para leerla, el proxy inverso enviará su contenido como respuesta. Si por alguna razón el archivo no se puede recuperar desde el cubo, el servidor devolverá un 404.
Si el cubo solicitado no está en la lista de Target_Buckets, entonces devolverá un 403, independientemente de su verdadero cubo o no.
Solo el método de solicitud GET es compatible actualmente.
Tener un solo modo de cubo significa que no hay necesidad de prefijo todas las solicitudes con una ruta de nombre de cubo, por lo que solicitar <proxy-host>:<proxy-port>/<file-path> solicitará la ruta del archivo desde el cubo de destino único.
Este proyecto usa Micro, lo que significa que podemos usar las excelentes herramientas de micro-dev, en desarrollo.
TARGET_BUCKETS="bucket-name" npm run dev
ADC utiliza la cuenta de servicio predeterminada que calcula el motor, el motor Kubernetes, el motor de aplicaciones y las funciones en la nube que proporcionan, para aplicaciones que se ejecutan en esos servicios.
Desde la configuración de la autenticación para aplicaciones de producción de servidor a servidor
Debido a lo anterior, le recomiendo que use el motor de cómputo, el motor Kubernetes o el motor de aplicaciones donde se manejará la autenticación para usted.
He suministrado un DockerFile para comenzar sin necesidad de instalar el nodo. Esto no funcionará localmente, ya que no configura ninguna autenticación con Google Cloud SDK.
Sin embargo, cuando se implementa en una autenticación de instancia de VM de motor de cómputo, se maneja para usted. Para ver cómo implementar una imagen de Docker en una instancia de VM, consulte esta guía. No olvide establecer la variable de entorno TARGET_BUCKETS , que se puede hacer siguiendo esta guía.
