Qualified names for reserved secret data fields in Provisioned Service

[baijum]

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:

• service_binding_type
• service_binding_provider

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

[scothis]

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]

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

[baijum]

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]

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]

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!