nilebox
commented
6 years ago Currently any credential is serialized into []byte first, and then we set Secret values via Data map[string][]byte, so internally Service Catalog already sets data as binary. It's Kubernetes Secret that encodes this binary data with base64:
https://github.com/kubernetes/api/blob/db88d6fb5927cf390f4d33133339a4fb0546399a/core/v1/types.go#L4634-L4639
So the real cause of double base64 encoding is that JSON doesn't natively support binary fields, and that there is no extra field in the JSON payload (or in the /catalog response) that would tell Service Catalog to decode the base64-encoded credential before serializing it into []byte. IMO it's a perfectly reasonable limitation for such generic spec as OSB. Otherwise the credential response structure would have been much more complex than just map[string]interface{}.
fejta-bot
ashokkkannan
k8s-ci-robot
Imagine that a broker returns a binary PFX certificate as one of the credentials. In order to do that, it needs to base64 encode it in the binding response JSON. The service catalog controller doesn't know the received string is base64-encoded.
If the controller stored the base64-encoded string in the Secret, everything would be fine, since the service consumer expects the credential to be in that form. But the problem is that the controller base64-encodes it again before storing it in the credentials Secret, so we end up with a doubly-encoded string. The service consumer must decode twice to get the original value.
I'm not sure we can do anything about it at this point, as there's no way for the controller to know whether a credential is already base64-encoded or not.
Related OSB API issue: https://github.com/openservicebrokerapi/servicebroker/issues/497