non-interactive "jsctl clusters connect" flow is broken about jsctl

[amcginlay]

@achuchev believes the code tries to create a second service account and this could be the permissions blocker. If this is the case, then maybe the approach would be for the code to recognise that the passed-in creds belong to an existing service account and just recycle the one provided.

[amcginlay]

@achuchev on further inspection this would appear to be a bug on the platform/server side rather than the CLI. Would you agree? Should we move it? This issue is causing problems with a customer enablement task I promised to deliver. The non-interactive workaround is not pretty at all.

[amcginlay]

https://github.com/jetstack/preflight-platform/pull/5221/commits/f8986e901f7b27e1cea1767bba040f167daa1b5c fixes this problem. Closing.

[amcginlay]

I spoke too soon, the flow remains broken (see below) but the aforementioned fix still helps pure-API users.

$ jsctl auth login --credentials ~/Downloads/credentials.json
$ jsctl config set organization gallant-wright
$ jsctl clusters connect kind_2303071902
failed to create service account: missing some roles in organization "gallant-wright": admin (403)

[achuchev]

@amcginlay With the latest update, we have enabled service accounts to create pull image secrets. Your latest error indicates a service account cannot create another. Let us process this and get back to you.

[amcginlay]

@achuchev This explains the previous confusion and I was just about to message you. Since I'm bypassing jsctl in my own work and the platform issue has been successfully addressed, this is no longer a requirement from me. Unless anyone else raises this please de-prioritize/close. Many thanks for your hard work.

[amcginlay]

Also, just a heads up but this issue may be the reason I have a lot of (non-visible) auth0 errors littering the user space:

$ curl -X 'GET' \
  'https://platform.jetstack.io/api/v1/org/gallant-wright/users' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer eyJhbGc...GSgxw' | jq .
[
...,
  {
    "user_id": "auth0|638e6738ebd471c46bb50e09",
    "email": "auth0|638e6738ebd471c46bb50e09",
    "name": "<Error: Not Found>",
    "picture_url": "",
    "verified": false,
    "created_at": null,
    "last_login": null,
    "is_deleted": true,
    "roles": [
      "member"
    ]
  },
  {
    "user_id": "auth0|63933775f498fd42e2fd3b7b",
    "email": "auth0|63933775f498fd42e2fd3b7b",
    "name": "<Error: Not Found>",
    "picture_url": "",
    "verified": false,
    "created_at": null,
    "last_login": null,
    "is_deleted": true,
    "roles": [
      "member"
    ]
  },
  ...
]

[j-fuentes]

Hey, you both are correct that service accounts cannot create other service accounts. This was like that by design.

I that becomes a requirement I would like to stop and think about that carefully. That might require work that we will throw away soon in the VaaS platform if we want to implement it with fine-grain controls. As an alternative, we could let any service account create service accounts, but that is something we would have to study the implication of carefully.

[j-fuentes]

Also, just a heads up but this issue may be the reason I have a lot of (non-visible) auth0 errors littering the user space:

$ curl -X 'GET' \
  'https://platform.jetstack.io/api/v1/org/gallant-wright/users' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer eyJhbGc...GSgxw' | jq .
[
...,
  {
    "user_id": "auth0|638e6738ebd471c46bb50e09",
    "email": "auth0|638e6738ebd471c46bb50e09",
    "name": "<Error: Not Found>",
    "picture_url": "",
    "verified": false,
    "created_at": null,
    "last_login": null,
    "is_deleted": true,
    "roles": [
      "member"
    ]
  },
  {
    "user_id": "auth0|63933775f498fd42e2fd3b7b",
    "email": "auth0|63933775f498fd42e2fd3b7b",
    "name": "<Error: Not Found>",
    "picture_url": "",
    "verified": false,
    "created_at": null,
    "last_login": null,
    "is_deleted": true,
    "roles": [
      "member"
    ]
  },
  ...
]

I think this might be an indication that when we delete service account the relation between the service account and the organization is left behind and it is orphan. We would need to look into this, but I don't think it is related to service accounts not having permissions to create other service accounts.