tenant controller: store access token instead of provider key

[eguzki]

https://issues.redhat.com/browse/THREESCALE-7911

what

This PR changes the tenant controller to store the access token owned by the admin user of the tenant in the tenant secret referenced in spec.tenantSecretRef.

Before this PR, the tenant controller stored the tenant provider key in the tenant secret referenced in spec.tenantSecretRef. However, the provider key has permission issues for some endpoints in the 3scale Account Management API ( THREESCALE-8276 and THREESCALE-6625 and THREESCALE-7911)

The desired UX would be:

• The customer installs 3scale and master access token is saved in system-seed
• The customer creates a Tenant CR] with a reference to the system-seed secret
• The customer creates Product CR and Backend CR with a reference to the tenant secret, which contains the access token.

how

Storing the access token owned by the admin user of the tenant is tricky because the tenant controller only has access to it in the response of the tenant creation 3scale API call. The access token is no longer accessible. This breaks somewhat the idempotent pattern followed by the controller. So, the implementation creates the tenant and immediately (before reconciling the admin user as it used to do), saves the access token in the tenant controller and then saves the tenant ID in the Tenant CR status field. I would like to remind without the tenant ID, there is no way to access the tenant. None the fields from the tenant is unique (like product's and backend's systemName). So storing the access token in the tenant secret and the tenant ID in the status is critical to have access to the recently created tenant. If any of the previous two steps fails, the recently created tenant will not be accessible and the controller will generate a new tenant. In that case, the previous tenant will be left unused.

verification steps

Deploy 3scale with APIManager CR

k apply -f - <<EOF
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: apimanager1
spec:
  wildcardDomain: example.com
  resourceRequirementsEnabled: false
  system:
    fileStorage:
      simpleStorageService:
        configurationSecretRef:
          name: aws-auth
EOF

Create a new tenant:

k apply -f - <<EOF
apiVersion: capabilities.3scale.net/v1alpha1
kind: Tenant
metadata:
  name: ecorp-tenant
spec:
  username: admin
  systemMasterUrl: https://master.example.com
  email: admin@example.com
  organizationName: ECorp
  masterCredentialsRef:
    name: system-seed
  passwordCredentialsRef:
    name: ecorp-admin-secret
  tenantSecretRef:
    name: ecorp-tenant-secret
EOF

The secret ecorp-tenant-secret should keep the access token and not the provider key of the new tenant as it used to be

The access token, allows to create backends and products linked to that backend.

First create the backend

k apply -f - <<EOF
---
apiVersion: capabilities.3scale.net/v1beta1
kind: Backend
metadata:
  name: backend-a
spec:
  name: "Operated Backend A"
  systemName: "backenda"
  privateBaseURL: "https://exampleA.com"
  providerAccountRef:
    name: ecorp-tenant-secret
EOF

Then create the product with references to the backend

k apply -f - <<EOF
---
apiVersion: capabilities.3scale.net/v1beta1
kind: Product
metadata:
  name: product1
spec:
  name: "OperatedProduct 1"
  backendUsages:
    backenda:
      path: /v1
  providerAccountRef:
    name: ecorp-tenant-secret
EOF

Both the backend and product resource status should show available condition

[MStokluska]

👀

[codeclimate]

Code Climate has analyzed commit 4565e04 and detected 6 issues on this pull request.

Here's the issue category breakdown:

Category	Count
Complexity	2
Duplication	2
Style	2

View more on Code Climate.

[MStokluska]

Tested on cluster, works as expected, looking at the code now

[MStokluska]

Tried it on cluster and it works as expected. Reviewed the code and it looks good to me.
/lgtm