I'm currently delivering a node + nestjs application via as a docker container using Google's Cloud Run.
I'm using the secrets manager for the secrets & using projects for dev/staging/prod and I'm trying to make the secrets available to my container in the cloud.
Current process is triggered by "yarn docker:auth" which triggers a series of bash scripts:
docker build -t gcr.io/my_project_id_dev/auth-service -f .docker/auth.DockerFile . &&
gcloud auth activate-service-account abc@my_project_id_dev.iam.gserviceaccount.com --key-file=gcloud-sa.json &&
gcloud auth configure-docker &&
docker push gcr.io/my_project_id_dev/auth-service &&
gcloud beta run services replace .gcp/cloud_run/auth.yaml &&
gcloud run deploy auth ... --allow-unauthenticated --platform managed --region europe-west2
The arguments/flags on the last command also doesn't work and I'm prompted to pick a platform & region every time I run it.
I've tried adding the flags to my auth.yaml file as well as the secrets as exemplified in the documentation for Google Cloud Build but it fails every time due to syntax error.
In the yaml file, I added the following at the bottom of the yaml file nested under no property:
availableSecrets:
secretManager:
- versionName: projects/my_project_id/secrets/mongo_uri/versions/latest
env: 'mongo_uri'
My questions is:
- Is it possible to do this via YAML at all?
I've also added a startup function to my nodejs app that tries to use @google-cloud/secret-manager
from npmjs to load the secrets into environment. I've got no issues doing this locally using the default credentials, but:
- Will the docker container inside Cloud run have any kind of "Default" credentials? and If not, what would be the best way to inject it? It seems bad practice to either build or ship the container with a service account key-file.
The fundamental issue I'm trying to solve is getting those secrets into the container environment.
Thank you.
EDIT:
Wanted to add the YAML part where I am assigning the service account to the cloud run container:
spec:
template:
metadata:
annotations:
autoscaling.knative.dev/maxScale: '2'
run.googleapis.com/client-name: cloud-console
run.googleapis.com/sandbox: gvisor
spec:
containerConcurrency: 2
containers:
- image: gcr.io/my_project_id/auth-service
ports:
- containerPort: 3000
resources:
limits:
cpu: 1000m
memory: 512Mi
serviceAccountName: abc@my_project_id.iam.gserviceaccount.com
timeoutSeconds: 300
But sadly this still results in this generic error:
(gcloud.beta.run.services.replace) Cloud Run error: Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.
With absolutely no further details within the logs themselves, blank! The container doesn't start locally due to no service account injected into it, but without that piece of code that handles the secrets-loading, the container starts locally just fine.
gcloud run deploy --service-account=SERVICE_ACCOUNT
where the service account represents the identity of the running revision, and determines what permissions the revision has gcloud command – marian.vladoi