Secrets App Release Notes

Note

Version 0.1.0 marks the Beta release of the ITRS Analytics Secrets app. This app release requires a minimum ITRS Analytics Platform version of 2.18.0 and Web Console version 3.8.0 to operate.

Secrets Beta 0.1.0 Copied

Released: xx July 2026 Beta

New features and enhancements Copied

These are the new features and enhancements of this release:

ITRS Analytics Secrets Beta 0.1.0 introduces the first beta of the Secrets app, giving teams a built-in way to store and manage application secrets inside ITRS Analytics. This beta focuses on secure handling of INTERNAL secrets, role-based access, and the deployment configuration needed to run the app in supported environments.

• Added the core Secrets service for storing INTERNAL secrets in the platform key-value store with encryption at rest, gRPC CRUD operations, and role-based access controls. This provides a secure backend foundation for managing secrets within ITRS Analytics.
• Added the first Secrets app user interface for creating, viewing, updating, and deleting INTERNAL secrets. The UI includes paginated listing, name filtering, masked secret values, and a reveal action so teams can manage secrets more safely from the Web Console.
• Added Helm and deployment defaults so the app installs with standard values only, including automatic encryption-key generation and an enabled gRPC service on port 9090 for supported app-to-app secret resolution.
• Added support for read-only INTERNAL secrets so platform-managed secrets can be viewed but not changed or removed through the public API or UI. The UI clearly identifies these entries and blocks mutating actions to reduce the risk of accidental changes.

About the Secrets app Copied

The Secrets app is a centralized secret-management service for ITRS Analytics. It lets teams store and manage named INTERNAL secrets in the platform key-value store (KVS), with AES-256-GCM encryption at rest, role-based access control, and a Web Console user interface for day-to-day administration.

In this beta release, INTERNAL secrets are the only supported secret type. These are secrets that the Secrets app owns and stores directly in platform KVS, rather than reading them from an external provider such as Vault. Administrators can create, view, update, and delete writable INTERNAL secrets through the UI and API, while some platform-managed INTERNAL secrets may be provisioned as read-only and cannot be changed or removed through public interfaces.

Each INTERNAL secret is stored by name, protected with role-based access checks, and encrypted before it is written to KVS. A caller must have the secrets permission and the matching owner_role to read the secret. In this beta, support for EXTERNAL secrets is deferred, so the documented workflows and examples in this page apply to INTERNAL secrets only.

This beta also provides a network gRPC interface so other ITRS Analytics apps can resolve secrets by name at runtime. For example, apps such as iax-app-ai can request a secret over gRPC instead of embedding sensitive values directly in their own configuration. The app also introduces a stateful encryption key, which must be handled correctly as part of backup and disaster recovery planning.

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.

This app provides the following benefits:

• 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 iax-app-ai 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.

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.
• Platform KVS and IAM services are available to the app.
• The Web Console shell is deployed so the Secrets app UI can be accessed.
• Your backup and disaster recovery process captures both the encryption key Secret and the encrypted Secrets app data stored in KVS.
• If you package the app with KOTS or another snapshot-based deployment workflow, ensure that the backup mechanism captures the existing encryption key Secret and restores it as-is.

Important

Back up and restore iax-app-secrets-encryption-keys and the encrypted KVS data as a matched pair. If the key Secret is lost because of cluster, etcd, namespace, or partial-restore failure, every encrypted secret becomes permanently undecryptable and cannot be recovered. Make sure your KOTS or platform backup process captures the existing Secret and does not regenerate or skip it during restore.

How to use in ITRS Analytics Web Console Copied

Follow these steps to create and manage secrets in the Web Console:

1. Install the Secrets app using the default chart values. No additional Helm flags are required for a standard install.

2. In ITRS Analytics Web Console, navigate to Admin > Secrets app.

3. Click Add Secret to create a secret.

4. Enter a unique secret name, optional description, an owner role selected from the roles assigned to your user account, and the secret value.

5. Save the secret. The app stores the value as an encrypted record in platform KVS.

6. Use the list view to review secrets, filter by name, description, or owner role, and open an existing secret for update or deletion.

7. When updating a secret, leave the value field empty if you want to keep the current stored value.

System-managed secrets are shown as read-only and cannot be edited or deleted through the public UI.

Configure the Secrets app Copied

The Secrets app is now installable with default values only, so no extra Helm flags are required for a standard installation. These are Helm chart default values defined in values.yaml and rendered into Kubernetes resources during installation. Two chart defaults were changed so a standard installation works out of the box:

• secrets.encryption.autoGenerate=true — On first install, the chart generates a random AES-256 master key and stores it in the Kubernetes Secret iax-app-secrets-encryption-keys. On upgrade, the chart reuses the existing key so previously encrypted data remains readable. The Secret is marked with helm.sh/resource-policy: keep, so it is intentionally retained after helm uninstall.
• secrets.grpc.enabled=true with the additional port grpc/9090/TCP — This enables the in-cluster gRPC interface so other apps can resolve secrets over the network without extra configuration.

Operators who want to manage the encryption key themselves can set secrets.encryption.autoGenerate=false and pre-create the iax-app-secrets-encryption-keys Secret before installing or upgrading the app.

If your teardown process expects a fully clean namespace after uninstall, note that retaining the encryption-key Secret is deliberate and that it is retained after uninstall. This allows a reinstall to continue decrypting previously stored secrets, but it should be accounted for in cleanup and packaging workflows.

Examples Copied

The following examples show how teams can use the Secrets app in common ITRS Analytics scenarios, from storing shared application credentials to managing secrets in the Web Console and preparing for backup and disaster recovery.

Store an API key for later reuse Copied

An administrator creates a secret named openApiKey, assigns it to the appropriate owner role, and saves the value in the Secrets app. A consuming app can then reference openApiKey by name instead of storing the API key in its own configuration.

Manage secrets safely in the UI Copied

An operator opens the Secrets app to review existing secrets, uses the filter field to find a specific entry, and updates the description or rotates the value as needed. Secret values remain masked in the interface unless the operator explicitly reveals them while editing.

Prepare for backup and disaster recovery Copied

Before a platform backup or migration, an administrator verifies that both the iax-app-secrets-encryption-keys Secret and the related encrypted KVS data are included in the same backup set. This ensures the secrets remain decryptable after restore.

Disclaimer

The information contained in this document is for general information and guidance on our products, services, and other matters. It is only for information purposes and is not intended as advice which should be relied upon. We try to ensure that the content of this document is accurate and up-to-date, but this cannot be guaranteed. Changes may be made to our products, services, and other matters which are not noted or recorded herein. All liability for loss and damage arising from reliance on this document is excluded (except where death or personal injury arises from our negligence or loss or damage arises from any fraud on our part).