Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QUESTION Secrets #2158

Closed
jiwanovski87 opened this issue Mar 14, 2022 · 5 comments
Closed

QUESTION Secrets #2158

jiwanovski87 opened this issue Mar 14, 2022 · 5 comments
Labels
question Further information is requested

Comments

@jiwanovski87
Copy link

Since the Azure Service Operator is designed to support GitOps I am wondering how we can retrieve secrets which are generated.

Example:
We are publishing a service which needs a redis cache and we need to put the information into a secret / configmap and mount these as volumes into the deployment of our service. In our config file we need to put in a CacheKey to access the redis cache.

So we have following resources defined in helm (a bit simplyfied):

  • ConfigMap which represents the config file for our service
  • Cache CRD
  • Deployment with a mountVolume referencing the ConfigMap

As far as I have seen in the documentation we need to call the ListKeys endpoit and need to develope an own hook... Is there any more detailed example or description?

@jiwanovski87 jiwanovski87 added the bug 🪲 Something isn't working label Mar 14, 2022
@matthchr
Copy link
Member

matthchr commented Mar 14, 2022

Great question!

So in ASO Beta-0 (which isn't out yet), we have a workflow implemented that solves this for you. The way it works is that you specify the following field on your cache CRD: .spec.operatorSpec.secrets

This defines a bunch of secrets:

  • primaryKey
  • secondaryKey
  • hostName
  • port
  • sslPort

Each of those fields is a SecretDestination, which is a name + key pair that defines where to put the value generated by Azure. After the Redis is created we will then automatically go call ListKeys and put the results of that call into the Kubernetes secret you defined. You can then mount that secret to your service pod and use it like you would any other Kubernetes secret.

See #1471, and #2101. You can read the full design here which shows some example YAMLs as well. The ListKeys mentioned in that design is the api we call in the operator. You shouldn't need to call it.

Note: The contents of .spec.operatorSpec.secrets is different for different resources. The one I described above is for Redis. There are others for Storage, CosmosDB, etc. This is because each Azure resource has a unique set of secret values that need to be exposed.

@matthchr matthchr added question Further information is requested and removed needs-triage 🔍 bug 🪲 Something isn't working labels Mar 14, 2022
@matthchr
Copy link
Member

This is a good reminder for me though, before beta0 comes out I'll write up better user-facing documentation for this, as it's not explained well at all.

@matthchr matthchr added this to the codegen-beta-0 milestone Mar 14, 2022
@jiwanovski87
Copy link
Author

@matthchr this sounds good :)
Do you already have an estimated date for ASO beta-0?

@matthchr
Copy link
Member

We have a milestone here you can look at. Items there will burn down as we approach release. In this case it looks like there's a lot of items left in the milestone but really most of them are already fixed and we're just waiting to close them until beta-0 actually ships. Those are the items tagged with the fixed-in-v2 tag.

Rough estimate for release is ~1 week from now (could be a bit earlier or take a bit longer but I wouldn't expect longer than 2 weeks from today).

@matthchr
Copy link
Member

Of course, it took longer than 2 weeks... but beta.0 is out now! Closing this as this is supported there. See how to retrieve secrets created by Azure

I have an example for cache in PR #2236.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
Development

No branches or pull requests

2 participants