Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC - Delivery of sensitive data to providers #4042

TrevinTeacutter opened this issue Feb 26, 2019 · 1 comment


Copy link

commented Feb 26, 2019

We have a particular issue (and potentially many others) around using Spinnaker to deliver things like Secrets to Kubernetes and DC/OS in that it does not actually have a mechanism to protect those secrets from exposure. While there are projects like sealed-secrets for Kubernetes, that doesn't allow for usage of Spinnaker's k8s versioning functionality which is desirable for the same reason it is for ConfigMaps. This means that secrets must be managed out of band of Spinnaker to get the full functionality which removes the ability for Spinnaker to really be the one stop shop for delivery of things to specific providers that might have to deal with secrets. Similar to #3969 I would like to propose an RFC for handling this problem:

  1. Leverage tools like for consumers to use to manage secrets in public spaces that can be pulled by spinnaker as http/file artifacts or this could necessitate the official support of a new artifact.
  2. Add upsert-secret operation within clouddriver that can leverage the same tool to decrypt the given artifact and upsert it to the specific provider (which would need to be declared within the pipeline stage).
  3. Add the concept of redactors that take anything cached by caching agents that could redact provider specific sensitive objects such that they would leak. This should be flexible in how it redacts those objects as well. For example the k8s secret object could allow for only leaves of the data tree to be redacted allowing for structural changes to be seen through spinnaker, but not the actual values of the leaves. Not sure on the implications of this on verifying that the change was applied but I'm sure there is a way to allow that to still happen.

Based just on our usage this would be useful for a few situations:

  1. Protects sensitive provider specific data from being exposed in pipeline executions that may be stored as change records AND protects it from being exposed in the UI since Clouddriver is the only one who should ever seen unencrypted contents.

  2. Allow versioning of secrets for the k8s provider without potentially being exposed in some manor. While this is a nice to have currently, if we expect consumers to be more proactive about rotating secrets, this makes that story significantly less fragile as far as the transition plan goes.

  3. This is more of a nice to have, but with something like SOPS we get flexibility in how consumers choose to encrypt their sensitive objects, mind you clouddriver has to know of these methods as well, I still think this would be a nice selling point.


This comment has been minimized.

Copy link

commented Mar 15, 2019

It seems there are at least 2 use cases.

  1. Use Hashicorp Vault or similar (cloud provider kms), put secrets in vault directly, use pod's service account to auth to Vault and retrieve secret.
  2. Inject k8s Secret's directly with Spinnaker.
    We've gone down this path and started deploying Sealed Secrets with Spinnaker without versioning. We are relying on a git revert or commit to drive a re-deploy rather than doing any roll back stage within the pipeline, ie: we are optimizing for Sealed Secrets one way flow, (leverages k8s RBAC, no ansible-vault edit, etc)
    If we wanted to use versioning I'd be tempted to open an issue and if suitable PR to the Sealed Secrets project. This seems to be a valid extension to me.

SOP's looked quite powerful too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.