Keep gitlab CI/CD variables secret in public repository
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?
gitlab gitlab-ci
asked Nov 10 at 22:54
Paymahn Moghadasian
1,53642337
add a comment |Â
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?
gitlab gitlab-ci
asked Nov 10 at 22:54
Paymahn Moghadasian
1,53642337
add a comment |Â
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?
gitlab gitlab-ci
asked Nov 10 at 22:54
Paymahn Moghadasian
1,53642337
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?
gitlab gitlab-ci
gitlab gitlab-ci
asked Nov 10 at 22:54
Paymahn Moghadasian
1,53642337
asked Nov 10 at 22:54
Paymahn Moghadasian
1,53642337
asked Nov 10 at 22:54
Paymahn Moghadasian
1,53642337
asked Nov 10 at 22:54
Paymahn Moghadasian
1,53642337
asked Nov 10 at 22:54
Paymahn Moghadasian
1,53642337
1,53642337
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
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.
answered Nov 11 at 0:48
VonC
829k28826093153
Even if I use KMS, won't my CI jobs need a decryption key? If the jobs have a decryption key, can't that beecho-ed and then used maliciously? Our plan is to only allow trusted developers access the cluster but I'm worried that making our repository public will give untrusted developers access to our cluster, which would be bad. I think private pipelines might be the right solution: docs.gitlab.com/ee/user/project/pipelines/…
– Paymahn Moghadasian
Nov 12 at 13:45
1
@PaymahnMoghadasian Agreed regarding KCM: that is what is mentioned in hk.saowen.com/a/…
– VonC
Nov 12 at 16:55
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Nov 11 at 0:48
VonC
829k28826093153
Even if I use KMS, won't my CI jobs need a decryption key? If the jobs have a decryption key, can't that beecho-ed and then used maliciously? Our plan is to only allow trusted developers access the cluster but I'm worried that making our repository public will give untrusted developers access to our cluster, which would be bad. I think private pipelines might be the right solution: docs.gitlab.com/ee/user/project/pipelines/…
– Paymahn Moghadasian
Nov 12 at 13:45
1
@PaymahnMoghadasian Agreed regarding KCM: that is what is mentioned in hk.saowen.com/a/…
– VonC
Nov 12 at 16:55
add a comment |Â
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.
answered Nov 11 at 0:48
VonC
829k28826093153
Even if I use KMS, won't my CI jobs need a decryption key? If the jobs have a decryption key, can't that beecho-ed and then used maliciously? Our plan is to only allow trusted developers access the cluster but I'm worried that making our repository public will give untrusted developers access to our cluster, which would be bad. I think private pipelines might be the right solution: docs.gitlab.com/ee/user/project/pipelines/…
– Paymahn Moghadasian
Nov 12 at 13:45
1
@PaymahnMoghadasian Agreed regarding KCM: that is what is mentioned in hk.saowen.com/a/…
– VonC
Nov 12 at 16:55
add a comment |Â
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.
answered Nov 11 at 0:48
VonC
829k28826093153
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.
answered Nov 11 at 0:48
VonC
829k28826093153
answered Nov 11 at 0:48
VonC
829k28826093153
answered Nov 11 at 0:48
VonC
829k28826093153
answered Nov 11 at 0:48
VonC
829k28826093153
829k28826093153
Even if I use KMS, won't my CI jobs need a decryption key? If the jobs have a decryption key, can't that beecho-ed and then used maliciously? Our plan is to only allow trusted developers access the cluster but I'm worried that making our repository public will give untrusted developers access to our cluster, which would be bad. I think private pipelines might be the right solution: docs.gitlab.com/ee/user/project/pipelines/…
– Paymahn Moghadasian
Nov 12 at 13:45
1
@PaymahnMoghadasian Agreed regarding KCM: that is what is mentioned in hk.saowen.com/a/…
– VonC
Nov 12 at 16:55
add a comment |Â
Even if I use KMS, won't my CI jobs need a decryption key? If the jobs have a decryption key, can't that beecho-ed and then used maliciously? Our plan is to only allow trusted developers access the cluster but I'm worried that making our repository public will give untrusted developers access to our cluster, which would be bad. I think private pipelines might be the right solution: docs.gitlab.com/ee/user/project/pipelines/…
– Paymahn Moghadasian
Nov 12 at 13:45
1
@PaymahnMoghadasian Agreed regarding KCM: that is what is mentioned in hk.saowen.com/a/…
– VonC
Nov 12 at 16:55
Even if I use KMS, won't my CI jobs need a decryption key? If the jobs have a decryption key, can't that be
echo-ed and then used maliciously? Our plan is to only allow trusted developers access the cluster but I'm worried that making our repository public will give untrusted developers access to our cluster, which would be bad. I think private pipelines might be the right solution: docs.gitlab.com/ee/user/project/pipelines/…– Paymahn Moghadasian
Nov 12 at 13:45
Even if I use KMS, won't my CI jobs need a decryption key? If the jobs have a decryption key, can't that be
echo-ed and then used maliciously? Our plan is to only allow trusted developers access the cluster but I'm worried that making our repository public will give untrusted developers access to our cluster, which would be bad. I think private pipelines might be the right solution: docs.gitlab.com/ee/user/project/pipelines/…– Paymahn Moghadasian
Nov 12 at 13:45
1
1
@PaymahnMoghadasian Agreed regarding KCM: that is what is mentioned in hk.saowen.com/a/…
– VonC
Nov 12 at 16:55
@PaymahnMoghadasian Agreed regarding KCM: that is what is mentioned in hk.saowen.com/a/…
– VonC
Nov 12 at 16:55
add a comment |Â
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53244223%2fkeep-gitlab-ci-cd-variables-secret-in-public-repository%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
