Token-based authentication
Authentication tokens allow a user to enter their credentials once, then receive an alphanumeric token to use to access different services or parts of the system infrastructure. Authentication tokens are tied to the permissions granted to the user through role-based access control (RBAC), and they provide the user with the appropriate access to HTTP requests.
- Activity service
- Code Manager
- Node classifier
- PuppetDB
- Puppet orchestrator
- RBAC
You can generate authentication tokens using the PE console,
the puppet-access
command, or the RBAC API v1 Tokens endpoints. You can also generate one-off tokens that do not need
to be saved, which are typically used by a service.
In the PE console, you can view or revoke your own tokens on the Tokens tab of the My account page. Administrators can view and revoke tokens for other users on the User details page. You can also Configure RBAC and token-based authentication settings in the PE Infrastructure node group.
Configure puppet-access
The puppet-access
command allows users to generate and manage
authentication tokens from the command line of any workstation (Puppet-managed or not), without the need to SSH into the primary
server. If you want to use puppet-access
, ensure it is
configured correctly before using it to generate authentication tokens.
The configuration file for puppet-access
allows you to define default
settings so that you can generate tokens from the CLI without having to pass additional
flags.
Whether you are running puppet-access
on a PE-managed server or installing it on a separate work station, you need a global
configuration file and a user-specified configuration file.
Global configuration file
The global configuration file is located at:
-
On *nix systems:
/etc/puppetlabs/client-tools/puppet-access.conf
-
On Windows systems:
C:/ProgramData/PuppetLabs/client-tools/puppet-access.conf
{
"service-url": "https://<CONSOLE_HOSTNAME>:4433/rbac-api",
"token-file": "~/.puppetlabs/token",
"certificate-file": "/etc/puppetlabs/puppet/ssl/certs/ca.pem"
}
service-url
setting.If you're running puppet-access
from a workstation not managed by PE, you must create the global file and populate it with
the required configuration file settings.
User-specified configuration file
The user-specified configuration file is located at
~/.puppetlabs/client-tools/puppet-access.conf
for both *nix and Windows
systems.
The user-specified configuration file always takes precedence over the global
configuration file. For example, if the two files have contradictory settings for the
token-file
, the user-specified setting prevails.
You must create the user-specified file and populate it with the configuration file settings. A list of configuration file settings is found in Configuration file settings for puppet-access.
Configuration file settings for puppet-access
You can manually add or edit configuration settings in your user-specified or global
puppet-access
configuration files.
The class that manages the global configuration file is:
puppet_enterprise::profile::controller
You can also change configuration settings by specifying flags when you Generate a token using puppet-access on the command line.
Setting | Description | Command line flag |
---|---|---|
token-file |
The location for storing authentication tokens. Defaults to:
~/.puppetlabs/token
|
-t or --token-file
|
certificate-file |
The location of the CA that signed the console-services
server's certificate. Defaults to the PE CA cert
location: /etc/puppetlabs/puppet/ssl/certs/ca.pem
|
--ca-cert |
config-file |
Changes the location of your configuration file. Defaults
to: ~/.puppetlabs/client-tools/puppet-access.conf
|
-c or
--config-file
|
service-url |
The URL for your RBAC API. Defaults to the URL automatically
determined during the client tools package installation process, which is
usually:
https://<CONSOLE_HOSTNAME>:4433/rbac-api Usually, you need to change this only if you are moving your console server. |
--service-url |
Generate a token in the console
Use the console to generate an authentication token that you can use to access PE APIs. If SAML is configured, you must have a token to use CLI tools, such as orchestrator jobs or PuppetDB queries triggered from the command line. Generate and export a token to the machine you want to run the CLI tool on.
Generate a token using puppet-access
Use the puppet-access
command to generate an authentication tokens
from the command line of any workstation (Puppet-managed or
not), without the need to SSH into the primary server.
The puppet-access
command uses RBAC API v1 Tokens endpoints. If your login credentials are correct, the RBAC
service generates a token.
The token is generated and stored in a file for later use. The default token storage
location is ~/.puppetlabs/token
. You can print the token at any
time, such as in curl commands, by using puppet-access show
.
You can continue to use this token until it expires, or until your access is revoked. The token has the same permissions as the user that generated it.
--debug
flag, the client outputs the token, as well as the username and password. For
security reasons, exercise caution when using the --debug
flag with
the login command.Generate a token using the RBAC API
The RBAC API v1 /auth/token
endpoint allows you to
generate a token.
You can use the token until it expires, or until your access is revoked. The token has the same permissions as the user associated with it.
Use a token with PE API endpoints
The example below shows how to use a token in an API endpoint request. For more information, refer to the documentation for the particular API or endpoint you want to use.
puppet-access login
.Generate a token for use by a service
If you need to generate a token that a Puppet Enterprise (PE) service can use, and the token doesn't need to
be saved, use the --print
option with the puppet-access
command.
sudo puppet-access login [username] --print
This command generates a token, and then displays the token content as stdout (standard output) rather than saving it to disk.
For information about modifying commands for Windows and privilege escalation, refer to Using example commands and Commands with elevated privileges.
View token activity
Token activity is logged by the activity service. You can see recent token activity on any user's account in the console.
- In the console, on theAccess control page, click the Users tab and select the full name of the user you are interested in.
- Click the Activity tab.
Change the default token lifetime
Tokens have a default authentication lifetime of one hour, but this default value can be adjusted in the console. You can also change the maximum permitted lifetime, which defaults to 10 years.
Set a token-specific lifetime
If you want a token to have a different lifetime than the default lifetime, you can set a different lifetime when you generate the token. This allows you to keep one token for multiple sessions.
If you Generate a token using puppet-access, use the
--lifetime
option. For example: puppet-access login
--lifetime 2h
generates a token with a two-hour lifetime.
lifetime
key. For example, this JSON body specifies a token
lifetime of two
hours:{"login": "<YOUR PE USER NAME>", "password": "<YOUR PE PASSWORD>", "lifetime": "2h"}
-
y
(years) -
d
(days) -
h
(hours) -
m
(minutes) -
s
(seconds)
12h
sets the lifetime to 12 hours.Do not add a space between the numeric value and the unit of measurement.
If you do not specify a unit, it is assumed to be seconds (s
).
To set the maximum possible lifetime, set the lifetime to 0
. This sets the lifetime to the value of
rbac_token_maximum_lifetime
. The default value for this setting is
10 years.
If omitted, tokens get the default lifetime, which is one hour, unless you Change the default token lifetime.
Set a token-specific label
You can affix a plain-text, user-specific label to tokens you generate with the RBAC v1 API. Token labels help you quickly call a token when working with RBAC API endpoints or when revoking your own token.
label
key
in requests to the POST /auth/token endpoint. The value
of the label
key becomes the token's label. For example: {"login": "<YOUR_PE_USER_NAME>",
"password": "<YOUR_PE_PASSWORD>",
"label": "My token"}
- Can't have more than 200 characters.
- Can't contain commas.
- Can't contain only spaces.
Whitespace is allowed within the label string; however, leading and
trailing whitespace is trimmed. For example, " my token
label "
becomes "my token
label"
.
Token labels are assigned on a per-user basis. This means two
users can both have a token labelled my token
, but a
single user cannot have two tokens both labelled my
token
.
You cannot use labels to refer to other users’ tokens.
Revoke a token using the API
Revoke tokens by username, label, or full token with the DELETE /tokens endpoint.
All token revocation attempts are logged in the activity service, and they can be viewed on the user's Activity tab in the console.
You can revoke your own token by username, label, or full token.
You can also revoke any other full token you possess.
Users with the permission to revoke other users access can also revoke those users'
tokens, because the users:disable
permission includes token revocation.
Revoking users' tokens does not revoke the users' PE accounts. If a user's
account is revoked, all tokens associated with that user account are also automatically
revoked.
Revoke a token in the console
Revoke your tokens on the My Account page in the console. Administrators can also revoke other users' tokens.
To revoke your own token:
- In the console, on the My account page, click the Tokens tab.
- Find the token you want to revoke and click Revoke token.
Delete a token file
If you used puppet-access
to generate a token, you can remove the
token file by running the delete-token-file
action. This is useful if you
are working on a server that is used by multiple people.
- If your token is at the default token file location,
run:
puppet-access delete-token-file
- If you used a different path to store your token file,
run:
puppet-access delete-token-file --token-path <TOKEN_PATH>