Skip to content
This repository was archived by the owner on Jun 4, 2025. It is now read-only.
This repository was archived by the owner on Jun 4, 2025. It is now read-only.

non-interactive "jsctl clusters connect" flow is broken #92

Open

Description

@amcginlay

The standard behaviour is that the user dances around a browser connected to TLSPK to complete the auth. This is not appropriate in non-interactive sessions where we'd like the sequence to be automatable. To this aim the jsctl auth login --credentials ${creds_file} syntax was introduced. To obtain a creds file, the user needs to create a TLSPK service account from here (https://platform.jetstack.io/org/<ORG_NAME>/manage/service_accounts) which looks something like this:

{
  "user_id": "bob@gallant-wright.platform.jetstack.io",
  "user_secret": "S5wF+IP......o@7g1\\Ty/"
}

So far so good, but we (@inteon) believe the service accounts are insufficiently privileged because the following happens:

$ jsctl auth login --credentials creds.json
Login succeeded
$ jsctl config set organization gallant-wright
Your organization has been changed to gallant-wright
$ jsctl clusters connect kind_2302201811
failed to create service account: missing some roles in organization "gallant-wright": admin (403)

Perhaps, what we really want is the ability to download equivalent credentials file for an org "Member", rather than a "Service Account".

I can see no reason why this shouldn't be possible since this is no different to how, for example, an AWS user obtains their AccessKeyID/SecretAccessKey pair. NOTE that AWS provides two such pairs per user at any time to enable safe credential rotation which might be a requirement.

Activity

  1. amcginlay commented on Mar 2, 2023

    @amcginlay
    Author

    @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.

  2. amcginlay commented on Mar 17, 2023

    @amcginlay
    Author

    @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.

  3. amcginlay commented on Mar 23, 2023

    @amcginlay
    Author

    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)
    
  4. achuchev commented on Mar 23, 2023

    @achuchev
    Contributor

    @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.

  5. amcginlay commented on Mar 23, 2023

    @amcginlay
    Author

    @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.

  6. amcginlay commented on Mar 23, 2023

    @amcginlay
    Author

    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"
        ]
      },
      ...
    ]
    
  7. j-fuentes commented on Mar 24, 2023

    @j-fuentes
    Contributor

    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.

  8. j-fuentes commented on Mar 24, 2023

    @j-fuentes
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions