ibm_compute_user

Provides a SoftLayer user resource. This allows you to retrieve, create, update, and delete either SoftLayer or IBMid accounts.

SoftLayer Account

If you use this resource to create SoftLayer local credentials, you need to define the username and password arguments.

To access the SoftLayer portal, the user can log in with the username and password.

To access the SoftLayer API, the user can log in with the username and API key. An api_key is generated by SoftLayer when the has_api_key flag is true.

If the SoftLayer API getBlueIdAuthenticationRequiredFlag returns false, the account is a local account.

Example Usage

The following example shows how to use this resource with SoftLayer accounts:

resource "ibm_compute_user" "joe" {
    address1     = "12345 Any Street"
    address2     = "Suite #99"
    city         = "Atlanta"
    company_name = "Comp Inc"
    country      = "US"
    email        = "joe@doe.com"
    first_name   = "Joe"
    has_api_key  = false
    last_name    = "Doe"
    username     = "testuser"
    password     = "Change3Me!"
    permissions  = [
        "ACCESS_ALL_GUEST",
        "ACCESS_ALL_HARDWARE",
        "SERVER_ADD",
        "SERVER_CANCEL",
        "RESET_PORTAL_PASSWORD"
    ]
    state        = "GA"
    timezone     = "EST"
}

IBMid Account

You can use an IBMid instead of your SoftLayer credentials. An IBMid is used as a consistent way to access IBM products. You can create an IBMid in advance.

If you use this resource for an IBMid account, the resource should not contain username and password arguments. The user name is generated by SoftLayer by combining the IBMid account number and the IBMid email address. The password is not used in an IBMid account.

To access the SoftLayer portal, the user can log in with the IBMid.

To access the SoftLayer API, the user can log in with the username generated by SoftLayer and the API key. An api_key is generated by SoftLayer when the has_api_key flag is true.

If the SoftLayer API getBlueIdAuthenticationRequiredFlag returns true, the account is an IBMid.

Example Usage

The following example shows how to use this resource with IBMid accounts:

resource "ibm_compute_user" "joe" {
    address1     = "12345 Any Street"
    address2     = "Suite #99"
    city         = "Atlanta"
    company_name = "Comp Inc"
    country      = "US"
    email        = "joe@doe.com"
    first_name   = "Joe"
    has_api_key  = false
    last_name    = "Doe"
    permissions  = [
        "ACCESS_ALL_GUEST",
        "ACCESS_ALL_HARDWARE",
        "SERVER_ADD",
        "SERVER_CANCEL",
        "RESET_PORTAL_PASSWORD"
    ]
    state        = "GA"
    timezone     = "EST"
}

NOTE: An IBMid is used as a consistent way to access IBM products. You can create an IBMid in advance.

For additional details, see the SoftLayer API documentation.

Argument Reference

The following arguments are supported:

  • address1 - (Required, string) The first line of the user’s street address.
  • address2 - (Optional, string) The second line of the user’s street address.
  • city - (Required, string) The user’s city.
  • company_name - (Required, string) The user’s company.
  • country - (Required, string) The user’s country.
  • email - (Required, string) The email address associated with the account.
  • first_name - (Required, string) The user’s first name.
  • has_api_key - (Optional, boolean) When the value is true, a SoftLayer API key is created for the user. The key is returned in the api_key attribute. When the value is false, any existing SoftLayer API keys for the user are deleted. The default value is false.
  • last_name - (Required, string) The user’s last name.
  • username - (Required for SoftLayer accounts, optional for IBMid accounts, string) A unique name to identify a user globally across all SoftLayer logins. The username is also the user login. Once a username is created, it cannot be changed. You must define a username when the account is a SoftLayer account. The user name is generated by SoftLayer when the account is an IBMid account. For example, if an IBMid had an account number of 1234567 and an email addess (IBMid) of test@example.com, then Softlayer would generate 1234567_test@example.com as the username. This argument is optional for an IBMid account.
  • password - (Required for SoftLayer accounts, string) The initial password for the user account. The password is hashed and encoded before it is stored in the Terraform state file. For an IBMid account, the password argument is ignored. For a SoftLayer account, the password must conform to SoftLayer’s password policies to avoid failures. Valid passwords must meet the following rules:
    • Be 8 to 20 characters in length.
    • Have a combination of upper and lowercase characters.
    • Contain at least one number.
    • Contain at least one of the following special characters: _, -, |, @, ., ,, ?, /, !, ~, #, $, %, ^, &, *, (, ), {, }, [, ], =.
  • permissions - (Optional, string) Permissions assigned to this user. This is a set of zero or more string values. See the SoftLayer API doc for user permissions.
  • state - (Required, string) The state of a user’s street address.
  • timezone - (Required, string) The user’s timezone as a short name value (e.g., “EST”). For accepted values, see the SoftLayer API doc for timezones .
  • user_status - (Optional, string) The user’s login status. You can find accepted values in the SoftLayer API doc for user status. The default value is ACTIVE.
  • tags - (Optional, array of strings) Tags associated with the user account instance.
    NOTE: Tags are managed locally and not stored on the IBM Cloud service endpoint at this moment.

Attribute Reference

The following attributes are exported:

  • api_key: The SoftLayer API key that is created for the user.
  • id: The unique SoftLayer identifier that is created for the user.
  • ibm_id: The username for IBMid accounts. This attribute is generated by SoftLayer when the IBMid is activated.

Additional Notes

In SoftLayer, there is a delay when user logins are deleted from SoftLayer backend systems. SoftLayer acknowledges delete requests and immediately updates the user status to CANCEL_PENDING. The actual deletion from the SoftLayer system processes at an unspecified time in the future.

This delay may be significant, especially during your project’s testing phase. You may receive an error if you create a user login, then delete it, and then create it again. This results in an error because the SoftLayer backend has not completely processed the previous delete operation. If you want create, delete, and recreate a user login, you must specify a new, globally-unique username in your subsequent requests.