search

servicebinding / spec

Specification for binding services to k8s workloads
https://servicebinding.io
Apache License 2.0
92 stars 35 forks source link

Qualified names for reserved secret data fields in Provisioned Service #96

Closed baijum closed 4 years ago

baijum commented 4 years ago

Current specification mandate using generic names as reserved secret data field names in Provisioned Service. The keys' names are type and provider. In real-world, these names could conflict with existing service secrets. I propose to qualify these reserved names with some prefix.

I would suggest names like this:

Apart from potential name conflicts, the name qualification will help to easily differentiate these names from other secret data fields.

scothis commented 4 years ago

Do you have an example conflict? Changing the key names doesn't eliminate the possibility of a conflict.

In my mind this is why it can be problematic to think of any arbitrary Secret as material for a binding instead of a Secret being a vehicle for the binding material. Bindable Secrets have additional requirements over opaque Secrets. The spec is clear about what those requirements are and among them is that the type and provider keys are reserved.

nebhale commented 4 years ago

I concur with this as well. Not just any Secret can be a Bindable Secret.

baijum commented 4 years ago

Do you have an example conflict?

No. I don't have any specific examples.

Changing the key names doesn't eliminate the possibility of a conflict.

Yes. But a more qualified name reduces the probability of conflicts.

In my mind this is why it can be problematic to think of any arbitrary Secret as material for a binding instead of a Secret being a vehicle for the binding material. Bindable Secrets have additional requirements over opaque Secrets. The spec is clear about what those requirements are and among them is that the type and provider keys are reserved.

Since these values are injected as volume mounts into the container, I am fine with the generic names. For environment-variables users can still re-use these names, right?

scothis commented 4 years ago

For environment-variables users can still re-use these names, right?

All envvars aside from SERVICE_BINDING_ROOT are custom and the user can specify any name they want.

baijum commented 4 years ago

For environment-variables users can still re-use these names, right?

All envvars aside from SERVICE_BINDING_ROOT are custom and the user can specify any name they want.

Thanks for the clarification. I am closing this issue!