Managing ChaosSearch API Keys

Users who have permission to use the ChaosSearch API endpoints to manage object groups, views, subaccount users, RBAC groups, and metadata can authenticate with their user and password. Storing and using passwords in programmatic API calls is not an optimal practice. Instead, users can generate an access key (which includes an associated secret key) for authentication of the API endpoints. Users can create and manage keys by using the API Keys page or by using ChaosSearch apiKeys endpoints.

Users can create access key IDs as needed for their purposes, up to the configured service limits per user and per system. For example, users might want to have one access key for each of their API applications. Users can also delete and create new keys as needed to meet the rotation/age-out policies at their sites.

The keys created by each user are stored in encrypted form in the customer's cloud-storage bucket where indexed data lives. When a subaccount is deleted, the access keys associated with that subaccount are likewise deleted.

📘

NOTE

At this time, the access/secret keys are not supported for husk users. End users must have an associated ChaosSearch subaccount to manage access keys for the API.

In earlier ChaosSearch releases, each user deployment received one API access key and secret key for authenticating API calls. All users who had ChaosSearch API permission used the same access key and secret. With this enhancement, there is no default overall key for the site; all users–root and subaccount–must create and manage their access keys/secrets as needed. Keys cannot be rotated to change their values; users must delete the old key and create a new one to perform a key rotation.

Users can create and delete their access keys, as well as list their current access key IDs, using the ChaosSearch interface or API calls.

🚧

IMPORTANT:

The secret key for an access key ID is visible only when a user creates an access key. Users can copy the key or download a CSV file of the access and secret key pair, and save the values to a vault or safe file location. It is not possible to display the secret value through the interface or API at a later point.