Create Provider using Username/Password to be able to generate tokens for other users

[mitchellmaler]

Our use case it to create a user using the user resource and then generate a token for that user which is then stored in our vault. Right now I am unable to find a way to create a user and then create a token for that user. I could create a new provider so that I can provide that users information but all I have it that users username, password, and id and there doesn't seem to be a way to impersonate or login using the provider with just that information.

Is there a way to create a provider using that users username/password or create a token for a newly created user?

[rawmind0]

BTM, this feature is not supported by the provider. Rancher API just supports token creation for "current" user.

Working to figure out a possible solution for that.

[mitchellmaler]

I know using the public api you can login using a local user by calling https://host.com/v3-public/localProviders/local?action=login which then returns a token for that user. Using this API the token resource or a new token type of resource could be setup to generate tokens for others if you have their username/password. https://host.com/v3-public api also allows logging in using the setup auth provider like active directory.

[rawmind0]

Sure, i know how this is working.Provider is already using these on bootstrap resource.

The solution i'm thinking is add the option to create token for rancher2_user resources. Once the local user is created, doing user login and creating a user token. May this work for you??

[mitchellmaler]

For me that would work perfectly!

Extra ask would be able to provide the ttl and description to the token creation/login if created using the rancher2_user resource but just being able to get a user token on user creation would be great.

[mitchellmaler]

@rawmind0 Do you know when this feature will be added?

[MG2R]

Just letting you guys know I found a "workable" workaround, at least for my use-case. Using the external data source and a small bash script, I am able to create tokens for arbitrary users and output them, using the workflow mentioned @mitchellmaler.

The caveats:

• the Rancher API only returns the actual secret token only once, after that it only outputs the ID. So you need to capture the Token when it gets created and save it. AFAIK it's not easily save-able in the TF state.
• the tokens get created during the plan phase, as the data source gets called in the plan phase. For my specific use case, that's not a problem. It might be for you, I don't know.

I'll see if my client will allow me to open-source the code. If you can live with the caveats, it's a nice workaround until the provider itself gets updated with this feature.

EDIT: It's better if you use the shell provider, which allows you to use scripts as resources instead of data sources, negating the caveats above.

[MG2R]

Good news: was allowed to share the workaround here. You can find it at the gist below.

https://gist.github.com/MG2R/52d0cf98635723f6485aa69785cb9831

[bkonick]

I am interested in this feature as well. It would be good to either add this feature, or to allow the provider to accept username/password so that we can create a token using a provider alias.

[sarg3nt]

Any update on when this will get done?
Our use case is for deploying Jenkins instances into a new project where we want to create a new user bound to that project and then create secrets with the token for the new user that Jenkins will then use to talk to Kubernetes to do builds. We have the user creation working fine but can't get the token for that user to create the secret.

[a-blender]

My team is doing a final review on the feature PR for this today. Target Terraform for Rancher 2.7.2

[snasovich]

Actually, this doesn't leave too much time to test. Kicking it out to the next release.

[a-blender]

@sboschman I have responded to an outstanding comment on your PR #932 here https://github.com/rancher/terraform-provider-rancher2/pull/932#discussion_r1192779148. Please make the requested naming changes and then it should be good to merge, thank you!

[sboschman]

PR #932 adds a new rancher2_custom_user_token resource. Together with the existing rancher2_user resource and rancher2_global_role_binding resource this resource can be used to create tokens for custom (Rancher) users.

Adding additional permissions to the custom user allows creating tokens to be used as "service account tokens" with the Rancher API.

Example:

# Create a rancher2 Token
resource "rancher2_user" "foo" {
  name = "foo"
  username = "foo"
  password = "changeme"
  enabled = true
}

resource "rancher2_global_role_binding" "foo-login" {
  name = "foo-login-binding"
  global_role_id = "user-base"
  user_id = rancher2_user.foo.id
}

resource "rancher2_custom_user_token" "foo" {
  username = rancher2_user.foo.username
  password = rancher2_user.foo.password
  description = "foo token"
  ttl = 0

  depends_on = [
    rancher2_global_role_binding.foo-login
  ]
}

[a-blender]

QA Test Template

Issue: https://github.com/rancher/terraform-provider-rancher2/pull/932

Problem

RFE for users to be able to create a custom user with an associated API token in Rancher via Terraform that is separate from the default admin user.

Solution

Solution defined here in the community PR, where a username/password for a rancher2_user (which is already an existing resource in Terraform) is provided to a new rancher2_custom_user_account_token resource to generate an API token for that custom user so the customer can login and provision clusters with that user. This was determined to be the simplest solution with the least drawbacks.

Test plan

Test steps

• Run a rancher v2.7-head instance
• Configure your main.tf to use Terraform v3.0.1 (once it's released) and a custom user account token as defined here
• Run terraform init
• Run terraform apply
• Verify that you can login to Rancher using the custom user account credentials
• Verify you can provision a downstream rke cluster via Terraform using the custom user account credentials and API token

Regressions Considerations

TFP user and API token generation. Already covered in plan above.

[markusewalker]

QA TEST PLAN

Scenarios

Scenario	Test Case
1	Create a standard user with an accompanying token using rancher2_custom_token resource, provision downstream K3S cluster using applicable rancher2 resources with the generated user
2	Create a restricted user with an accompanying token using rancher2_custom_token resource, provision downstream RKE2 cluster using applicable rancher2 resources with the generated user

[markusewalker]

Validated that this is addressed on v2.7-head https://github.com/rancher/rancher/commit/0bcf068e1237acafd4aca01385c7c6b432e22fd7 using TF version 3.1.0-rc1. See results below:

ENVIRONMENT DETAILS

• Rancher install: Docker
• Rancher version: v2.7-head https://github.com/rancher/rancher/commit/0bcf068e1237acafd4aca01385c7c6b432e22fd7
• Terraform version: 3.1.0-rc1
• Browser: Chrome

TEST RESULT

Scenario	Test Case	Result
1	Create a standard user with an accompanying token using rancher2_custom_token resource, provision downstream K3S cluster using applicable rancher2 resources with the generated user	:white_check_mark:
2	Create a restricted user with an accompanying token using rancher2_custom_token resource, provision downstream RKE2 cluster using applicable rancher2 resources with the generated user	:white_check_mark:

VALIDATION STEPS

Scenario 1

1. In a client machine, created a main.tf with the following configuration:

erraform {
  required_providers {
    rancher2 = {
      source = "rancher/rancher2"
	 version = "3.1.0-rc1"
    }
  }
}
provider "rancher2" {
  api_url   = <omitted>
  token_key = <omitted>
  insecure  = true
}
resource "rancher2_user" "user" {
  name = "standard"
  username = "<omitted>"
  password = "<omitted>"
  enabled = true
}
resource "rancher2_global_role_binding" "standard-login" {
  name = "standard-login-binding"
  global_role_id = "user"
  user_id = rancher2_user.user.id
}
resource "rancher2_custom_user_token" "custom-token" {
  username = rancher2_user.user.username
  password = rancher2_user.user.password
  description = "custom user token"
  ttl = 0
  depends_on = [
    rancher2_global_role_binding.standard-login
  ]
}

2. Validated that the above created a new standard user with its own token in the Rancher UI:
3. Using the rancher2_cluster_v2 resource, validated that the generated user with its bearer token could provision a downstream K3S v1.26.4+k3s1 node driver cluster.
4. Validated that all workloads are up and Active in the system project page.
5. Ran command terraform destroy and validated that the cluster and its resources were cleaned up from Rancher.
6. Using the default admin user's bearer token, successfully removed the created standard user and its token.

---

Scenario 2

1. Repeated scenario 1, but utilized the following configuration instead for a restricted admin user:

terraform {
  required_providers {
    rancher2 = {
      source = "rancher/rancher2"
	 version = "3.1.0-rc1"
    }
  }
}
provider "rancher2" {
  api_url   = <omitted>
  token_key = <omitted>
  insecure  = true
}
resource "rancher2_user" "user" {
  name = "restricted"
  username = "<omitted>"
  password = "<omitted>"
  enabled = true
}
resource "rancher2_global_role_binding" "restricted-login" {
  name = "restricted-login-binding"
  global_role_id = "restricted-admin"
  user_id = rancher2_user.user.id
}
resource "rancher2_custom_user_token" "custom-token" {
  username = rancher2_user.user.username
  password = rancher2_user.user.password
  description = "custom user token"
  ttl = 0
  depends_on = [
    rancher2_global_role_binding.restricted-login
  ]
}

3. Noted the same successful results as outlined in scenario 1, but for a restricted admin user provisioning a downstream RKE2 v1.26.5+rke2r1 node driver cluster.