GCS Reverse Proxy
1.0.0
Um proxy reverso de armazenamento do Google Cloud. Para hospedar sites estáticos privados usando objetos privados de armazenamento em nuvem do Google.
Você deseja atender sites estáticos usando seus baldes GCS, mas deseja restringir o acesso a eles.
Esse micro serviço de proxy reverso se comportará como um servidor HTTP simples para uma matriz de baldes GCS. Em seguida, você pode usar qualquer método apropriado para restringir o acesso a ele. Por exemplo, colocando -o atrás do Nginx, Caddy ou uma VPN.
O acesso a objetos GCS privados através do navegador requer tokens especiais que são codificados no URL. Isso quebrará a maioria dos sites estáticos (se não todos), pois eles não podem gerar esses tokens ou prever o URI de qualquer ativo que solicita ou vincule. No entanto, tornar um objeto de armazenamento público significa que não há como restringir o acesso a ele.
Esse proxy reverso servirá a um objeto privado sobre HTTP no URI esperado (relativo) e não restringirá o acesso a esses objetos. No entanto, ao colocar esse servidor por trás de outro proxy reverso, como o Nginx ou colocá -lo em uma VPN, você poderá controlar o acesso de uma maneira que os melhores atendam às suas necessidades.
NB (se você tiver o GCLOUD SDK Instalado Run
gcloud infoem seu shell para verificar se você está conectado e possui o conjunto de identificação de projeto correto).
O TARGET_BUCKETS Env var espera uma lista separada por vírgula de baldes, por exemplo:
TARGET_BUCKETS='bucket-one,bucket-two'
O servidor jogará a menos que um ou mais Target_Buckets sejam definidos.
Definir o HISTORY Env var como true iniciará o servidor no modo histórico, para obter melhor suporte ao spa. Ele responderá com o arquivo ROOT index.html de baldes para qualquer caminho que não tenha uma extensão de arquivo.
npm install
TARGET_BUCKETS="bucket-name" npm start
Depois que o servidor estiver em funcionamento, para acessar um objeto privado em um balde, deve fazer uma solicitação para:
<proxy-host>:<proxy-port>/<bucket-name>/<file-path>
Se o caminho do arquivo existir no balde e o servidor tiver a premissa para lê -lo, o proxy reverso enviará seu conteúdo como resposta. Se, por qualquer motivo, o arquivo não for recuperado do balde, o servidor retornará um 404.
Se o balde solicitado não estiver na lista de Target_buckets, ele retornará um 403, independentemente de um balde real ou não.
Somente o método de solicitação GET é suportado atualmente.
Ter um único modo de balde significa que não há necessidade de prefixar todas as solicitações com um caminho de nome de balde; portanto, solicitar <proxy-host>:<proxy-port>/<file-path> solicitará o caminho do arquivo do balde de destino único.
Este projeto usa o Micro, o que significa que usamos as excelentes ferramentas micro-DEV, em desenvolvimento.
TARGET_BUCKETS="bucket-name" npm run dev
O ADC usa a conta de serviço padrão que calcula o mecanismo, o mecanismo de kubernetes, o mecanismo de aplicativos e as funções em nuvem fornecem, para aplicativos que são executados nesses serviços.
Da configuração de autenticação para aplicativos de produção de servidor para servidor
Por causa do exposto, recomendo que você use o mecanismo de computação, o mecanismo de kubernetes ou o mecanismo de aplicativos onde a autenticação será tratada para você.
Eu forneci um Dockerfile para começar sem precisar instalar o nó. Isso não funcionará localmente, pois não configura nenhuma autenticação com o Google Cloud SDK.
No entanto, quando implantado em um mecanismo de computação, a autenticação da instância da VM é tratada para você. Para ver como implantar uma imagem do Docker em uma instância da VM, consulte este guia. Não se esqueça de definir a variável de ambiente TARGET_BUCKETS , que pode ser feita seguindo este guia.
