Red Hat Advanced Cluster Security for Kubernetes (RHACS) requires API tokens for some system integrations, authentication processes, and system functions. You can configure tokens using the RHACS web interface.

  • To prevent privilege escalation, when you create a new token, your role’s permissions limit the permission you can assign to that token. For example, if you only have read permission for the Integration resource, you cannot create a token with write permission.

  • If you want a custom role to create tokens for other users to use, you must assign the required permissions to that custom role.

  • Use short-lived tokens for machine-to-machine communication, such as CI/CD pipelines, scripts, and other automation. Also, use the roxctl central login command for human-to-machine communication, such as roxctl CLI or API access.

Creating an API token

  1. In the RHACS portal, go to Platform ConfigurationIntegrations.

  2. Scroll to the Authentication Tokens category, and then click API Token.

  3. Click Generate Token.

  4. Enter a name for the token and select a role that provides the required level of access (for example, Continuous Integration or Sensor Creator).

  5. Click Generate.

    Copy the generated token and securely store it. You will not be able to view it again.

About API token expiration

API tokens expire one year from the creation date. RHACS alerts you in the web interface and by sending log messages to Central when a token will expire in less than one week. The log message process runs once an hour. Once a day, the process lists the tokens that are expiring and creates a log message for each one. Log messages are issued once a day and appear in Central logs.

Logs have the format as shown in the following example:

Warn: API Token [token name] (ID [token ID]) will expire in less than X days.

You can change the default settings for the log message process by configuring the environment variables shown in the following table:

Environment variable

Default value



1h (1 hour)

The frequency at which the log message background loop that lists tokens and creates the logs will run.


24h (1 day)

The frequency at which the loop lists tokens and issues notifications.


168h (1 week)

The time period before expiration of the token that will cause the notification to be generated.