Portable Service Definitions

[pierreozoux]

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!

[pierreozoux]

/sig apps

[pierreozoux]

There are also these 3 links relevant to this discussion:

• https://blog.upbound.io/introducing-crossplane-open-source-multicloud-control-plane/
• https://blog.crossplane.io/postgresql-crossplane-rook/
• Create RDS Resource Type amazon-archives/aws-service-operator#39

[pierreozoux]

Here is the repo I'd like to discuss: https://github.com/pierreozoux/StandardResourceDefinitions

[mattfarina]

@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.

[unteem]

@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.

[kacole2]

Hello @pierreozoux , I'm the Enhancement Lead for 1.15. Can you update the original post to follow the standard format?

# Enhancement Description
- One-line enhancement description (can be used as a release note):
- Kubernetes Enhancement Proposal: (link to kubernetes/enhancements file, if none yet, link to PR)
- Primary contact (assignee):
- Responsible SIGs:
- Enhancement target (which target equals to which milestone):
  - Alpha release target (x.y)
  - Beta release target (x.y)
  - Stable release target (x.y)

Is this feature going to be graduating alpha/beta/stable stages in 1.15? Please let me know so it can be tracked properly and added to the spreadsheet.

Once coding begins, please list all relevant k/k PRs in this issue so they can be tracked properly.

[justaugustus]

/assign @pierreozoux