docs
docs copied to clipboard
secretKeyRef example needs an explanation for a common, but weird, case
What content needs to be created or modified? The example for the "How to Reference Secrets in Components in https://docs.dapr.io/operations/components/component-secrets/ needs to be expanded to cover a common, but weird, case. I have encountered this, and recently this has come up in Dapr Discord in this thread https://discord.com/channels/778680217417809931/778680217417809934/833723505408213032.
Here is the yaml for the current example in Dapr Docs:
apiVersion: dapr.io/v1alpha1 kind: Component metadata: name: statestore namespace: default spec: type: state.redis version: v1 metadata:
- name: redisHost value: localhost:6379
- name: redisPassword secretKeyRef: name: redis-secret key: redis-password auth: secretStore: <SECRET_STORE_NAME>
Here is the explanation for the above example:
"The above component definition tells Dapr to extract a secret named redis-secret from the defined secret store and assign the value of the redis-password key in the secret to the redisPassword field in the Component"
All of the above is OK, but does not cover the following case.
Describe the solution you'd like Below is the yaml that I use for retrieving a connection string from the Azure Key Vault. And this same style also applies to alvinh's example in the above cited thread, using the AWS Secret Manager:
apiVersion: dapr.io/v1alpha1 kind: Component metadata: name: svs-servicec-inputq-azkvsecret-asbqueue spec: type: bindings.azure.servicebusqueues version: v1 metadata:
- name: connectionString secretKeyRef: name: AsbNsConnString key: AsbNsConnString
- name: queueName value: servicec-inputq
auth: secretStore: svs-secrets-azurekvsecretstore-test1
The above technique took a number of time consuming experiments to discover, assisted by C. Mendible. It will be better if it is documented since it seems to be a common case for dealing with complete connection strings across several secret stores.
Recall this works as follows "extract a secret named redis-secret from the defined secret store and assign the value of the redis-password key in the secret to the redisPassword field in the Component."
In the above case there is NO key in the secret to assign to the receiving field in the component. Rather the entire contents (not an embedded key) of the secret (a connection string) needs to be assigned to the AsbNsConnString field in the Component. Generalized, the specific case is when there is no key in the secret, but rather the secret is an entire string, then both the secret name and secret key will be identical.
One could go a step further and modify the component so that it also supports an entire string, aka a secret without an embedded key, in addition to a situation with an embedded key. Thus there would be different yaml for each situation, with one or the other required. This would be much more user friendly, since the above is rather convoluted, confusing, and not at all intuitive. But at least if it is documented as it it will not take hours of experimentation and asking questions on Discord to figure out how to do a common task such as retrieving a connection string from a secret store!
Where should the new material be placed? Place the above explanation as a note under the existing text in the document.
Additional context
@georgestevens99 Thank you.
@georgestevens99 I'm assigning this to you. Can you create a PR?
@orizohar What are your expectations of me when you say you are assigning it to me? And to create a PR? Do you mean you want me to modify the document as I stated in the issue and then make a PR so my modifications can be reviewed? Thanks.
The attached MS Word document contains the text from "How to Reference Secrets in Components" in https://docs.dapr.io/operations/components/component-secrets/ that has been modified to bring that document up-to-date with the changes required by this issue.
All the original text remains untouched. I have added new text which is ALL UNDERLINED, except for the yaml I also added and which is self evident.
Would someone please assist me by copying the underlined changes, plus the new yaml example, from the attached Word document and pasting them into appropriate places in the Dapr Docs document at https://docs.dapr.io/operations/components/component-secrets/. And then submit a PR?
I would greatly appreciate that assistance since I am short on spare time, and do not want spend my time climbing up the Hugo installation and editing learning curve required to submit a PR myself. It has taken me an 1.25 hours make these changes and come up with wording that is both accurate and kind of easy to read in this difficult-to-explain area. Thanks.
It is now 8/24/21 and the end of my "short on spare time" situation is within sight. So I plan to do the work with Hugo to incorporate the changes in the above Word document into Dapr Docs by mid-next week.
Resolved - closing