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

Portable Service Definitions #706

pierreozoux opened this Issue Jan 20, 2019 · 5 comments


None yet
4 participants
Copy link

pierreozoux commented Jan 20, 2019

The KEP already exists, but there were no issue, so creating this one.
(I'm new here, so please forgive me or give me guidance on how to proceed)

I'm interested in working on that, and I'd like guidance on how to move this forward.

About the secrets, I'd like to mention this project from appscode - AppsBinding which is the ServiceCatalog equivalent of binding.

I think that this KEP asks again the question of Operator vs Service Catalog, and I keep asking this to myself, but I think I found the answer in this thread.

And then, to move this forward, I think we need the following:

  • standard CRDs
    • MySQL
    • PostegreSQL
    • Redis
    • ObjectStorage
    • Database Snapshot
    • ...
  • kindly ask/PR the current implementation to use them

To list them in a cluster, we can just label them I guess. But at the end of the day, all CRDs are special services to the end user. So I don't see a big difference between a normal CRD and a standard CRD.

For kubernetes project, there is not much code to write/maintain. We'll need to write/maintain this list of CRDs, and then write automation/validation.

Looking forward to see this happen!


This comment has been minimized.

Copy link

pierreozoux commented Jan 21, 2019

/sig apps

@k8s-ci-robot k8s-ci-robot added sig/apps and removed needs-sig labels Jan 21, 2019


This comment has been minimized.


This comment has been minimized.

Copy link

pierreozoux commented Jan 24, 2019

Here is the repo I'd like to discuss:


This comment has been minimized.

Copy link

mattfarina commented Jan 29, 2019

@pierreozoux I'll poke at the different topics here as I get a chance. The first is the AppsBinding. Thanks for pointing me to the post on it.

One problem is the way the credentials are stored in the AppBinding CRs. They are stored in plain text inside etcd and don't appear to be mountable via things like environment variables. ConfigMaps and Secrets have a special place in Kubernetes in their ability to do that.

Secrets have been going through a bit of backend work lately. Where there used to be a flag for encrypting the data of secrets (alpha feature being enabled) there is now work to back secrets with KMS providers.

I would like to see anything we do with credentials get looped into the security mechanisms already being worked on.

Secrets have a type field. This is often set to Opaque. In our case we were looking to have different types with schemas. It's not currently as easy to validate as a CR/CRD but the tradeoff is in the security and being able to use the details for things like environment variables or volume mounting.

Kubernetes is starting to take securing credentials much more seriously, which is needed for many users and use cases, and I would like to see the work here leverage that.


This comment has been minimized.

Copy link

unteem commented Jan 30, 2019

@mattfarina from what I understand its not the secret part of the credentials that are set in clear in the CR. The part of the credentials that are secrets, are referenced in the CR by their secret name see for example how it is used in kubevault.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment