users

Description

The users property defines the user accounts to be created. The name field will be the name of the account and the passwordSecret field is the name of the secret that contains the credentials for the user account. The access-level and group property define the access-level, either privileged or group-defined, and the group, if access-level is group-defined. If using groups, it is expected that the configuration provided for the default domain would define the user group in RBM settings. This property does not create the group, it just creates a user assigned to the specified group.

An admin account must be defined. By default, an admin account is defined using the secret name admin-credentials. You can either create a secret with that name containing the credentials for the admin account, or use a different secret name by changing the passwordSecret field for the admin user in the CR.

The following are values in the secret which can be used to define the user's credentials:

• password-hashed: The hashed value (see Linux man 3 crypt for format) of the user's password. Required if password is not defined.
• password: The user's password. Required if password-hashed is not defined; ignored if password-hashed is defined.
• salt: The salt value used when hashing password (see man 3 crypt). Optional; ignored when password-hashed is defined. (Default: 12345678)
• method: The name of the hashing algorithm used to hash password. Valid options: md5, sha256. Optional; ignored when password-hashed is defined. (Default: md5)

The following examples create Secrets with different values, but result in an user with the same credentials (and the same password hash):

• kubectl create secret generic userName-credentials --from-literal=password=helloworld --from-literal=salt=12345678 --from-literal=method=md5
• kubectl create secret generic userName-credentials --from-literal=password=helloworld
• kubectl create secret generic userName-credentials --from-literal=password-hashed='$1$12345678$8.nskQfP4gQ8tk5xw6Wa8/'

These two examples also result in Secrets with different values but identical user credentials

• kubectl create secret generic userName-credentials --from-literal=password=hunter2 --from-literal=salt=NaCl --from-literal=method=sha256

• kubectl create secret generic userName-credentials --from-literal=password-hashed='$5$NaCl$aOrRVimQNvZ2ZLjnAyMvT3WgaUEXoWgwkgyBrhwIg04'

  Notice that, when setting password-hashed, the value must be surrounded by single-quotes

For more information, read the Kubernetes documentation on Secrets.

Example

apiVersion: datapower.ibm.com/v1beta3
kind: DataPowerService
metadata:
  name: example-dpservice
spec:
  users:
  - name: admin
    passwordSecret: admin-credentials
    access-level: privileged
  - name: user1
    passwordSecret: user1-credentials
    accessLevel: group-defined
    group: group1
  - name: user2
    passwordSecret: user2-credentials
    accessLevel: group-defined
    group: group2
  ...