Feature: Support to reference Configmaps and Secrets

[anandpatra18]

I am currently primarly interested and working with the APIM CRDs.
I am in contact with the product group of APIM and ASO via backbase for this .

One feature disucssed was the requirement to have ability to refer configmaps and secrets for inputs to out CRD attributes for example the APIM reference id can be referred from a ConfigMap or a API spec required by the API spec can also be referred from a configmap.

We were suggested to raise a issue on this repo for the ASO developers to add this feature into the operator.

Can we get some advise on this or if this is planned ?

[theunrepentantgeek]

This sounds like something we'd likely want to land for our next release of ASO v2.

Which APIM properties in particular do you want exposed? You give the APIM reference id as an example, what else?

We don't have a mechanism to do a blanket export of everything - and that wouldn't make sense for most properties anyway. Instead, we will individually export specific properties.

[anandpatra18]

Thanks for the response. Indeed we also do not expect a blanket export of all.
we were expecting something like referring to ConfigMaps as we do in deployments or other kubernetes objects.
Something like this

owner:  
    armId:   
      valueFrom:   
           configMapKeyRef:   
                name: apim-config 
                 key: apim.resourceid

And for other attributes we would like to have the ability to reference are below

1. kind: Api : spec.value . This is the API specification in yaml or json format which currently can be passed as string or a file reference during helm deployment. But if we create a configmap containing this api spec we would like to refer to that spec for this.
2. kind: Policy: spec.value. Similar to the above here we would also like policy xml to be reffered from a configmap instead of passing a file or string in the helm deployment
3. kind: Backend spec.url. This property is to configure a backend object in APIM and if the url can be fetched from configmap would give us lot of flexibility
4. kind:user . This is a yet to be released CRD but i hear it is in the works. For this i can imagine the password attribute should have the ability to be reference from a kubernetes secret

These are a few scenarios i was able to come up with. There could be more with time.
Hope this explains the feature request a bit more.

[matthchr]

The example you gave above shows pulling an armId from a configmap specifically for owner field. That shouldn't really be required because if there's an ASO resource that corresponds to that ARM ID, you can use owner.name to refer to the resource in Kuberentes rather than using the armId field.

Does that help solve your problem?

we were expecting something like referring to ConfigMaps as we do in deployments or other kubernetes objects.

Most other Kubernetes objects actually dont allow references to ConfigMaps, it's primarily used as a mechanism to drive configuration to Pods/Deployments. AFAIK things like Services, etc in Kuberentes don't have configMap integration.

I'm not sure that I'm entirely following the examples you gave above where you show how you'd like to use this - could you share the full CRD specification (with secrets redacted, if needed) and which bits you want to source from a configmap and why?

[anandpatra18]

We do not plan to have the APIM service provisioned via the ASO hence cannot use the owner.name attribute.
APIM is going to be provisioned and managed by terraform in our case hence we will still need the owner.armId attribute to refer to the correct instance.

Indeed services ,etc do not support but most kubernetes workloads(Deployments,stateful set .etc) allow this hence it would really help configure our APIM resource deployments in this manner.

I can explain the examples in any other way if you have a suggestion, i had explained this to the APIM PG team in MSFT and they had seen the value of this feature and they suggested us to raise this issue on the repo for ASO team to take it further.

But at this moment i can say atleast the armId reference is a feature which will help us a lot in automation and set up and a robust CI/CD process for out APIM component deployments.

[matthchr]

For configuration management details, where the values are statically known prior to deployment, we strongly recommend people using existing tools such as Helm, Kustomize, or <insert-favorite-tool-here>. The secret and config map features in ASO are generally intended for dynamic values that aren't known prior to deployment - such as service endpoints and API keys generated by Azure.

You can also import the resource into ASO without ASO actively managing it via the reconcile-policy: skip annotation. So instead of creating a configmap and flowing the ARMID through there you can import the resource and let it be visible in the cluster too.

IDs feel special initially but we think that really they're not different than other fields. For example, you may have a requirement that service teams deploy their resources into a particular region, or define a particular set of environments (dev, test, prod, etc). Since all of these constraints are known upfront, tools like Kustomize or Helm, with the appropriate overlays (Kustomize) or charts + values (Helm) is a more generic solution that allows you to customize more than just what owner a resource has.

[anandpatra18]

Thanks for the update matt, seems logical enough. Will try to work with it in this manner as you suggested and will get back if we still think that feature will be helpful.

[matthchr]

Going to go ahead and close this for now. Once you've tried some of the above we can reopen this if it's still needed