GCS Reverse Proxy
1.0.0
Un proxy inversé de stockage Google Cloud. Pour l'hébergement de sites statiques privés utilisant des objets de stockage Google Cloud privés.
Vous souhaitez desservir des sites statiques à l'aide de vos seaux GCS, mais vous souhaitez vous limiter l'accès.
Ce service micro-proxy inversé se comportera comme un simple serveur HTTP pour un tableau de seaux GCS. Ensuite, vous pouvez utiliser n'importe quelle méthode appropriée pour y restreindre l'accès. Par exemple, le mettant derrière Nginx, Caddy ou un VPN.
L'accès aux objets GCS privés via le navigateur nécessite des jetons spéciaux codés dans l'URL. Cela brisera la plupart (sinon la totalité) des sites statiques, car ils ne peuvent pas générer ces jetons ou prédire l'uri des actifs auxquels il demande ou aux liens. Cependant, rendre un objet de stockage public signifie qu'il n'y a aucun moyen de restreindre l'accès à lui.
Ce proxy inversé servira un objet privé sur HTTP au niveau (relatif), URI et ne limitera pas du tout l'accès à ces objets. Cependant, en mettant ce serveur derrière un autre proxy inversé, tel que Nginx ou en le mettant sur un VPN, vous pourrez contrôler l'accès d'une manière qui convient le mieux à vos besoins.
NB (si vous avez le SDK gcloud installé, exécutez
gcloud infodans votre shell pour vérifier que vous êtes connecté et avez le bon jeu d'identification de projet).
Le TARGET_BUCKETS Env Var s'attend à une liste de seaux séparés par des virgules, par exemple:
TARGET_BUCKETS='bucket-one,bucket-two'
Le serveur lancera à moins qu'un ou plusieurs Target_Buckets ne soient définis.
La définition de l' HISTORY Env Var sur true démarrera le serveur en mode historique, pour une meilleure prise en charge de SPA. Il répondra avec le fichier root index.html des bucket pour tout chemin qui n'a pas d'extension de fichier.
npm install
TARGET_BUCKETS="bucket-name" npm start
Une fois le serveur en cours d'exécution, accéder à un objet privé dans un seau devrait faire une demande de GET à:
<proxy-host>:<proxy-port>/<bucket-name>/<file-path>
Si le chemin du fichier existe dans le seau et que le serveur a une prémission pour le lire, le proxy inversé enverra son contenu en réponse. Si, pour une raison quelconque, le fichier n'est pas récupérable à partir du seau, le serveur renvoie un 404.
Si le seau demandé n'est pas dans la liste de Target_Buckets, il renverra un 403, quel que soit son véritable seau ou non.
Seule la méthode de la demande GET est actuellement prise en charge.
Le fait d'avoir un seul mode de godet signifie qu'il n'est pas nécessaire de préfixer toutes les demandes avec un chemin de nom de seau, donc demander <proxy-host>:<proxy-port>/<file-path> demandera un chemin de fichier dans le seau cible unique.
Ce projet utilise Micro, ce qui signifie que nous utilisons les excellents outils micro-DEV, en développement.
TARGET_BUCKETS="bucket-name" npm run dev
ADC utilise le compte de service par défaut qui calcule le moteur, le moteur Kubernetes, le moteur d'application et les fonctions cloud, pour les applications qui s'exécutent sur ces services.
De la configuration de l'authentification pour les applications de production de serveur vers le serveur
En raison de ce qui précède, je vous recommande d'utiliser le moteur Calcul, le moteur Kubernetes ou le moteur d'application où l'authentification sera manipulée pour vous.
J'ai fourni un dockerfile pour commencer sans avoir à installer le nœud. Cela ne fonctionnera pas localement car il ne configure aucune authentification avec Google Cloud SDK.
Cependant, lorsqu'il est déployé sur une authentification d'instance de VM de moteur de calcul est géré pour vous. Pour voir comment déployer une image Docker sur une instance VM, consultez ce guide. N'oubliez pas de définir la variable d'environnement TARGET_BUCKETS , qui peut être effectuée en suivant ce guide.
