Store and manage secrets in ITRS Analytics

Beta

The Secrets app is currently available as a beta release. Features, behavior, and documented procedures are subject to change without prior notice during ongoing development. For information about major and minor updates, see the Secrets app release notes.

About the Secrets app Copied

The Secrets app helps you store and manage sensitive values such as API keys, access tokens, and other application credentials in ITRS Analytics. Use it when you want to keep secret values out of everyday application configuration and manage them from a single location in the Web Console.

In beta version 0.1.0, the app supports INTERNAL secrets only. These are secrets that you create and manage in the Secrets app itself. You can create, view, update, and delete writable INTERNAL secrets in the Web Console, while some platform-managed INTERNAL secrets can appear as read-only and cannot be changed or removed in the app.

Each secret is stored by name, protected with role-based access checks, and encrypted at rest before it is written to platform storage. You assign an owner role when you create a secret, and users must have that same role to work with it. Support for external secret providers is not part of this beta release, so the documented procedures in this guide apply to INTERNAL secrets only.

This beta version also introduces the first supported app-to-app secret resolution workflow for ITRS Analytics. The secret-resolution API is a general ITRS Analytics platform interface, so any compatible in-cluster ITRS Analytics app can integrate with it. In this beta, the Agentic SRE app is the first supported integration and can reference a stored secret by name instead of storing a provider API key directly in its own configuration.

The Secrets app provides the following capabilities for day-to-day use:

• Create, view, update, and delete writable INTERNAL secrets in the Web Console.
• Assign an owner role to each secret so access can be controlled by role.
• Filter secrets by name, description, or owner role to find them quickly.
• Enter secret values in masked fields and reveal them only when needed during editing.
• Work with read-only secrets that are provided by platform workflows or integrations.
• Use stored secrets from supported apps such as the Agentic SRE app.

Prerequisites Copied

Before using the Secrets app, ensure the following requirements are met:

• ITRS Analytics Platform 2.18.0 or later and Web Console 3.8.0 or later.
• The Secrets app is installed and available in the Web Console.
• Your deployment provides the required platform identity and storage services for the app.

Use case scenarios Copied

This section explains where the Secrets app helps in day-to-day operations. The app gives platform administrators and application teams a controlled way to store, protect, and reuse secrets across ITRS Analytics without exposing plaintext values in application configuration.

Centralize application secrets Copied

Use the Secrets app to store sensitive values such as API keys, tokens, and integration credentials in one managed location.

Key use cases:

• Avoid hardcoding secrets in app values files, deployment manifests, or local configuration.
• Reuse the same managed secret across supported ITRS Analytics apps.
• Reduce operational risk by keeping secret values encrypted at rest and access-controlled by role.

Benefits include:

• Better security posture — Secrets are protected in platform storage instead of being spread across multiple configuration locations.
• Simpler administration — Teams can manage secrets from the Web Console in one place.
• Lower configuration drift — Applications reference a secret by name instead of duplicating the same value in several deployments.

Support app-to-app secret resolution Copied

Use the Secrets app when one ITRS Analytics app must retrieve a secret securely from another app at runtime.

Key use cases:

• Allow supported apps such as the Agentic SRE app to resolve secrets over the in-cluster gRPC interface.
• Keep secret ownership and access checks in one service instead of reimplementing them in each consuming app.
• Enable platform-managed, read-only secrets for controlled internal integrations.

This app provides the following benefits:

• Faster onboarding for dependent apps — The default install now exposes the gRPC service automatically, so no additional install flags are required for standard deployments.
• More consistent security controls — The same role-based access checks apply whether a secret is accessed from the UI or by another app.
• Better operational resilience — The chart reuses the existing encryption key on upgrade so previously stored ciphertext remains valid.

How to use in ITRS Analytics Web Console Copied

Use the following procedures to create and manage secrets in the Web Console.

Create a secret Copied

1. In ITRS Analytics Web Console, go to Admin > Secrets.

2. Click Add Secret.

3. Enter a unique Name for the secret.

4. Optional. Enter a Description to help other users understand what the secret is for.

5. In Owner role, select the role that should be allowed to use and manage the secret. The available values come from the roles assigned to your account.

6. Enter the secret Value.

7. Click Save.

   

Find and review a secret Copied

1. Go to Admin > Secrets.
2. Use the list view to review available secrets.
3. Use the filter field to narrow the list by name, description, or owner role.
4. Select a secret to open its details.

Update a secret Copied

1. Open the secret that you want to change.
2. Update the secret name, description, or value as needed.
3. Leave the value field empty if you want to keep the current stored value.
4. Keep the existing owner role. The owner role is immutable and cannot be changed during update.
5. Click Save.

Delete a secret Copied

1. Open the secret that you want to remove.
2. Confirm that it is not marked as read-only.
3. Click Delete and complete the confirmation.

Read-only secrets are visible in the app, but they cannot be edited or deleted.

Manage access with roles Copied

Use roles to control who can view and manage each secret.

When you create a secret, choose an Owner role that matches the group of users who should be allowed to use and manage that secret. For example, if a secret should be managed only by administrators, select the admin role.

Use the following guidance when assigning roles:

• Choose admin when the secret should be managed by administrative users only.
• Choose a non-admin role, such as user, when the secret should be available to that role instead.
• Only assign a role that appears in the Owner role list for your account.

After a secret is created, users must have access to the Secrets app and hold the same owner role to work with that secret.

For example:

• Users with the admin role can create secrets owned by admin.
• Users with the admin role can view, update, or delete writable secrets owned by admin.
• Users without the matching owner role cannot view or manage that secret in the app. Secrets they do not own are not shown in the list, and direct attempts to open them return Secret not found.

The admin role is useful for restricting a secret to administrators, but it does not automatically grant access to every secret. Access still depends on the owner role assigned to each secret.

The owner role is immutable after a secret is created. If you need to assign a different owner role, delete the secret and create it again with the new role.

Work with read-only secrets Copied

Some secrets are managed by the platform and appear in the Secrets app as read-only.

When a secret is read-only:

• You can view that it exists in the Secrets app.
• You cannot edit or delete it through the Secrets app.
• This restriction applies to all standard users, including users with the admin role.

If you need to change a read-only secret, follow your organization’s platform administration or change-management process for the application or workflow that provided that secret.

Store API keys for the Agentic SRE app Copied

Use the Secrets app to store the API key that the Agentic SRE app needs for an LLM provider, such as OpenAI.

Note

The secret-resolution API is a general platform interface that can be used by compatible in-cluster ITRS Analytics apps. In this beta release, the Agentic SRE app version 0.5.0 or later is the first supported integration. The Secrets app is also required when you install the Agentic SRE app in the KOTS Admin Console.

Key use cases:

• Store the provider key once as a named secret, such as openApiKey, instead of copying the plaintext value into the Agentic SRE app configuration.
• Configure the Agentic SRE app to use the API Key (Secret) field so the LLM configuration references the secret by name.
• Allow the Agentic SRE app to resolve the stored secret at request time instead of storing the credential value directly in the LLM configuration.

Use the following procedure:

1. In the Secrets app, create a secret for the provider API key. For the default OpenAI example, use the secret name openApiKey.
2. Assign an owner role that matches the users who must be allowed to use that secret. In the default integration example, openApiKey is typically owned by the user role. This is important because the Agentic SRE app resolves the secret by using the calling user’s credentials. If the secret is owned by admin, non-admin users cannot resolve it and their requests fail.
3. Save the secret.
4. In the Agentic SRE app, open the LLM configuration and use the API Key (Secret) field to enter the secret name, for example openApiKey, instead of pasting the plaintext API key into the LLM settings.
5. Save the LLM configuration.
6. Test the configuration and confirm that the Agentic SRE app can use the stored secret successfully.

This app provides the following benefits:

• Safer LLM configuration — The Agentic SRE app stores a secret reference instead of the provider API key value.
• Better reuse — You can rotate the stored secret in one place without manually updating every dependent configuration.
• Consistent authorization — Access to each secret still depends on the permissions and owner role assigned to that secret.