Built-in support for managing secrets

[Haishi2016]

It's desirable that OAM provides native support for describing secrets such as passwords and certificates.

[novettaberin]

This is critical. putting plain passwords and tokens in plain text is really really bad.

[resouer]

@bericoberin Yes, we fully agree! While note that users can use secretKeyRef in OAM Kubernetes runtime.. For example, feel free to define a component like below:

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: frontend
  annotations:
    description: Container workload
spec:
  workload:
    # a k8s workload CR
    apiVersion: apps/v1
    kind: Deployment
    spec:
  containers:
    - name: web
      image: php:latest
      env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: username

The mysecret Secret object will be managed by infra engineer or auto-generated by some other component (e.g. a MySQL component).

@Haishi2016 Would like to know your idea around how secret can be modeled better in OAM model. Please check the scenario of data input/output PR which should be closely related to this discussion: https://github.com/crossplane/oam-kubernetes-runtime/pull/53/file

In that proposal, we can achieve data input/output, but the developer still need to claim the secret key explicitly because we can't model Secret for now. If we could, we can achieve very nice user experience because use only need to claim the ENV key and OAM runtime could inject everything it needs automatically. /cc @wonderflow , maybe you two could sync offline about this issue.

[novettaberin]

The concept of a Secret mapping trait can work for simple cases, as can your environment variable approach above.

However, with OAM, how about mapping ConfigMaps and Secrets to the filesystem? For example, one of the secrets that has to be managed would be a web server key for TLS, and the trust store certificates--particularly for PKI environment. Typically, those need to be stored on the filesystem and referenced at run time.

It seems with all the examples, things that would normally be kept as a k8s Secret are out in the open. That's fine for a proof of concept, but doesn't help for a more realistic scenario.

[resouer]

with OAM, how about mapping ConfigMaps and Secrets to the filesystem

@bericoberin So the idea is defining a ConfigureFile or ConfigureStore object in OAM and allow it to have different backends. For example, Kubernetes Secret, or Azure Keyvault secrets. And we could then reference this object in data output section of crossplane/oam-kubernetes-runtime#53. Correct?

[tomkerkhove]

I think having a seperate SecretStore SecretProvider which is responsible for:

• Authenticating with the underlying system (kubernetes, HashiCorp Vault, Azure Kubernetes, AWS Secrets Manager, etc)
• Getting secrets (and determining if mem-caching is required)

Applications can then use these and pass them to their workloads, either via environment variables or mounted volumes. They choose where they should end up in; not the operator as he might not know what's expected.

If this becomes a separate trait you can even take it a step further and provide the capability to:

• Send out CloudEvents to notify workloads of change (support for hot reload/app update - We already do this for Azure Key Vault and it's powerful)
• Plug in auditing
• ...

All of this, without the workload to worry about it.