Keep gitlab CI/CD variables secret in public repository

Question

I have a private project on Gitlab with CI/CD set up to push/pull docker images from Google Container Registry and to deploy my software to Kubernetes Engine in GCP.

Is there a way to make my project public without worrying about the secrets used to connect to GCP getting leaked? In particular, I'm worried that when my repository is public anyone would be able to add a line like echo $GCP_REPOSITORY_SECRET somewhere in the .gitlab-ci.yml file, push their branch and view the output of the CI to "discover" my secret. Does Gitlab have a mechanism to prevent this? More fundamentally, are there best practices to keep deployment secrets secret for public repositories?

Answer 1

More fundamentally, are there best practices to keep deployment secrets secret for public repositories?

Yes, don't have any sensitive data in it. Ever.

At the GCP level, the secret management options are listed here.

When connecting a GitLab-CI to GCP, you can see the security implication here, which uses kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 -D, with the right account and RBAC.

The whole cluster security is based on a model where developers are trusted, so only trusted users should be allowed to control your clusters.

---

Note that GitLab 11.7 (January 2019) allows for:

Configure Kubernetes app secrets as variables for Auto DevOps pipelines

Operators and administrators require that the configuration of secrets takes place outside the application’s repository to reduce risk and exposure of sensitive data.
To address this need, GitLab now offers the ability to configure secrets as environment variables that are made available to the Auto DevOps application running in your Kubernetes cluster.

Simply prepend your variable with K8S_SECRET_ and the relevant Auto DevOps CI pipeline will take your application secret variable to populate a Kubernetes secret.

Answer 2

Masked variables are ridiculously easy to unmask...

echo ${MASKED_VARIABLE::1} ${MASKED_VARIABLE:1} // mind the gap \!

You may want to PROTECT them instead; AND, make sure that only truly trusted devs can push to your protected branches.