Make default namespace configurable

[vazirim]

operator should look for seed-secret in current namespace, and if not present, in the namespace specified in seed-defaults, using a naming convention (one seed-secret per namespace)

[pdettori]

Some more details on the design we discussed with @vazirim:

1. We can maintain back compatibility with the current design, by adding a configuration parameter in the seed-defaults config (secrets-namespace).
2. If secrets-namespace is not specified we look first in the namespace of the resource being created, and if no seed-secret is found there, we fall back to the default namespace to look for seed-secret there.
3. If the secrets-namespace is specified, and noseed-secret is found in the namespace for the resource being created, then we look for a secret with name seed-secret-<resource-namespace> in the namespace indicated by secrets-namespace

[cdlliuy]

@pdettori just curious, are the names seed-secret and seed-defaults configurable? If we put them into the end-user's namespace where the service/bind resource being created, I would like to use a more explicitly name , i.e. secret-ibm-cloud-operator and config-ibm-cloud-operator to avoid the deletion by end-user.

[vazirim]

@cdlliuy Sure, we can rename.

Just to be clear, every namespace will still need a seed-default configmap, because this is what will tell us where to look for the secret. It will also contain the context (org/space/resource group) corresponding to that namespace.

[cdlliuy]

I guess the org/space is optional , right? it is a concept for cf.

[vazirim]

yes but the resourcegroup is needed for non-cf.

[ZhuangYuZY]

@pdettori After some thinking, I think we may reconsider the design. One major concern is from security.
From security perspective, IBM service can not store any customer sensitive information. So coligo can not store customer apikey into an system namespace, it could only be in customer's namespace.

So far I do not have a good idea how to resolve the problem. Suggest to hold on and use seed-secret in user's namespace which open to all namespace users. Will follow this issue later after discuss with more people to get feedback.

What do you think ? Thank you.

[pdettori]

@ZhuangYuZY yes, I can see how this makes sense from security perspective. If there is a concern about users accessing the IAM API Key from the secret, one possible approach is to give the IAM API Key only the minimum permissions required to create IBM Cloud Services.

[ZhuangYuZY]

Yes, now we are working on to try to create a service id with minimum permission to create IBM Cloud service and credential. But seems IBM Cloud operator can not work well with service id, so we created issue #98 to track it. It will be priority for us.
Thank you.

[vazirim]

Fixed in v0.1.7