operate on multiple tyk orgs

[asoorm]

At present, Tyk Operator only operates on a single organization.
This means that multiple operators need to be deployed if:

• Multiple teams need their own operator
• A single Tyk installation is deployed in multi-tenent configuration
• There are several tyk installations installed in the cluster

If Tyk Operator were able to operate on multiple organizations, this would be significantly more efficient.

https://github.com/TykTechnologies/tyk-operator/blob/master/docs/installation/installation.md#tyk-operator-configuration

This also means, that in a multi-org operator configuration, we could deprecate the following configuration options:

• TYK_ORG
• TYK_AUTH
• TYK_URL
• TYK_TLS_INSECURE_SKIP_VERIFY

And each operand (Tyk Organization or Tyk Installation) could be configured in a separate configmap / CRD.

---

Considerations:

• For simplicity & backward compatibility, ability to run in single org mode - same as now
• Is it possible for the permissions of the user who created the custom resource (kubectl apply) to determine which Tyk Org to use?
• If not, in multi org mode, it would be necessary to x-reference every single CR object with the organization - is this usable / feasable?

---

Related:

• Do you need an operator for every organisation in a multi tenant installation? #243

[gernest]

I think we can have Organization crd that the operator will be working with. This resource will own the API definitions/Policies.

• TYK_ORG
• TYK_AUTH
• TYK_URL
• TYK_TLS_INSECURE_SKIP_VERIFY

These env vars stays the same only TYK_ORG should be derived from the resource that will be referenced in the API definition.

[asoorm]

OperatorContext to support multi-tenancy in the Operator was introduced in v0.7.0 - https://github.com/TykTechnologies/tyk-operator/releases/tag/v0.7.0