GitHub Access Control API and Admin User

Archive Rancher 1.x
1

Continuing the discussion from Remote Authentication:

I created a script that setups GitHub access control to a newly created Rancher server. It looks like this:

cat auth-payload.json \
| sed "s/\[\clientid]/${client_id}/g" \
| sed "s/\[\clientsecret]/${client_secret}/g" \
| http POST "${rancher_url}/v1-auth/config"

I am passing a client id and client secret generated from GitHub and it successfully provisions the server with GitHub access control. Now, the payload contains a single allowed identity that is:

"allowedIdentities": [
  {
    "externalId": "2295585",
    "profilePicture": "https://avatars2.githubusercontent.com/u/2295585?v=4",
    "name": "Miguel Enriquez",
    "externalIdType": "github_user",
    "profileUrl": "https://github.com/ElderMael",
    "login": "ElderMael",
    "role": "owner",
    "projectId": null,
    "user": false,
    "all": null,
    "id": "github_user:2295585",
    "kind": "admin"
  }
]

But once I log in to the server I can see that my account is a normal user account instead of an admin account.

Now, when I click the “Authenticate with GitHub” button I see the same HTTP payload as the one I am generating but I do not see how the admin account is linked to my identity.

Any ideas on how to link/create an admin account while provisioning Access Control with Github?

Note this from the linked topic:

I fail to see any HTTP request linking the current admin account (or creating a new admin account) while going through the UI and enabling GitHub access control.

2

For what I see in the enable and test page code I see that the Ember model saves the allowed identity and then refreshes the page… but for some reason I just cannot see if that action does link the admin account to the identity.

let model = this.get('model').clone();
      model.setProperties({
        'enabled': true,
        'accessMode': 'restricted',
        'allowedIdentities': [auth.userIdentity],
      });

Update: I think it is here where the admin kind is set the first time you create a project.

But after looking at the code looks like my user is actually going to this phase because it has never logged in:

            if ((hasLoggedIn == null || !((Boolean) hasLoggedIn)) &&
                    !authDao.hasAccessToAnyProject(identities, false, null)) {
                projectResourceManager.createProjectForUser(user);
            }

Thus I am inclined to make a request to get a token in order to fail this assertion. I can verify that my user has its own project because when I loggin I see a project named “Default-Eldermael”.

3

The “test” step (posting to get a token) associates the externalId of the person who successfully authenticated with the 1a1 account (which is already an admin).

You can do the same in your code, but that requires interaction with github. Or just set the externalId on 1a1 directly.

Without that being done there is no user with your github ID on login, so a new user and project are created for them.

4

You mean that something like this should be in the payload?

"allowedIdentities": [
  {
    "externalId": "1a1",
    "profilePicture": "https://avatars2.githubusercontent.com/u/2295585?v=4",
    "name": "Miguel Enriquez",
    "externalIdType": "github_user",
    "profileUrl": "https://github.com/ElderMael",
    "login": "ElderMael",
    "role": "owner",
    "projectId": null,
    "user": false,
    "all": null,
    "id": "github_user:2295585",
    "kind": "admin"
  }
]
5

No… Identities are the representation of a user/group/org/etc in an external auth system (in this case github)

Allowed identities in the auth config controls the set of users which are allowed to login. They may or may not already have accounts in Rancher.

Once someone does log in, they get an actual account in the database. The externalId field on the account ties the Rancher account to the external auth identity.

What the UI does (Indirectly via generating a token to test that the auth config is good) is update the existing admin account (which is always 1a1 in a clean setup) so that the externalId on it points to the user setting up auth (in this case github_user:2295585). This makes you the existing admin account, and the owner of all the projects that were created while auth was off.

But you can just update the account directly yourself before enabling auth, which is useful for github in particular because the test token flow would require back-and-forth with github and parsing to emulate on your own.

PUT /v2-beta/accounts/1a1 {"externalId":"github_user:2295585"}

1 Like
6

It worked but I had to add another field:

http PUT "${rancher_url}/v2-beta/accounts/1a1" \
        externalId=2295585 externalIdType=github_user

Otherwise the admin id was something like 1a1!github_user:github_user:2295585. Can’t say what happens there.