Kumoss
prerelease Prerelease stable Latest
↑↓ navigate · ↵ select · esc close
Kumoss
Kumoss
prerelease Prerelease stable Latest

Secrets and credentials

Every secret Kumoss consumes, plus authentication, project-level authorization, LLM, Git, and cloud-engine credentials for a production deployment.

This is the first of four pages that expand Deploy to production: once the reference topology and the sidecar boundaries are decided, this page is every credential and secret the deployment must supply — the inventory, then authentication, project-level authorization, LLM, Git, and cloud-engine credentials in turn.

Secrets inventory

Keep the variable names; replace the .env files with your platform’s secret injection. Every value below is a secret or credential.

Secret Consumed by Variable(s) Notes

LLM provider credentials

Core

Provider-specific: ANTHROPIC_API_KEY (the shipped anthropic/ default); AZURE_AI_API_KEY + AZURE_AI_API_BASE (azure_ai/); AZURE_API_KEY + AZURE_API_BASE + AZURE_API_VERSION (azure/); VERTEXAI_PROJECT + VERTEXAI_LOCATION + VERTEXAI_CREDENTIALS

Names per provider in LLM providers and models. Checked at boot for most providers — but not for all of them, and azure_ai/ in particular fails on the first LLM call instead (Startup credential validation and its limits).

IaC bearer token

Core and IaC sidecar

KUMOSS_IAC_TOKEN

Must match on both sides.

Notifications bearer token

Core and notifications sidecar

KUMOSS_NOTIFICATIONS_TOKEN

When enabled.

Mapping bearer token

Core and mapping sidecar

KUMOSS_MAPPING_TOKEN

When enabled.

Authorization bearer token

Core and authorization sidecar

KUMOSS_AUTHZ_TOKEN

When enabled.

Git credentials

Core

GIT_USER, GIT_TOKEN

One token for every session: a service account with the minimum permissions to push branches and open and merge pull requests on the repositories in scope.

Database URL

Core

KUMOSS_SQL_DATABASE_URL

Embeds the password. postgresql:// and sslmode= are rewritten for the async driver.

Redis URL

Core

KUMOSS_REDIS_URL

When Redis needs a password or lives outside the cluster network.

Object-storage credentials

Core

RUSTFS_ACCESS_KEY + RUSTFS_SECRET_KEY (S3-compatible and static S3 keys), or nothing for the AWS default credential chain, or STORAGE_ACCOUNT_KEY (Azure)

Variable names can be changed through storage.*_env. They serve the artifacts bucket and, where Kumoss-managed state is enabled, the state bucket — in which case a non-empty value is also embedded into the backend block the IaC sidecar executes.

Cloud credentials for the engine

IaC sidecar

ARM_*, GOOGLE_*, AWS_*, mounted files, or workload identity

Read by the providers, not by Kumoss. They must also cover the state backend — Kumoss’s bucket by default, when the rendered backend block carries no static keys, or the repository’s own if you set storage.terraform_state_bucket to "". The role must be on the sidecar, not only the core.

Slack webhook URL

Notifications sidecar

SLACK_WEBHOOK_URL

Anyone holding it can post to the channel.

Phoenix database URL

Phoenix

PHOENIX_SQL_DATABASE_URL

Phoenix’s own setting.

Rules: generate tokens with a cryptographic generator, one per sidecar; rotate on a schedule and immediately on suspicion; never put a secret in config.yaml, in an image, or in a log; make mounted credential files readable by uid 10001.

Authentication (OIDC)

Mandatory. Follow Enable authentication for your identity provider. In summary:

  1. Register a public single-page-application client using the authorization code flow with PKCE. No client secret exists.

  2. Register <origin>/auth/callback as the redirect URI and <origin> as the post-logout URI, where <origin> is your TLS origin.

  3. Set oidc.issuer_url, oidc.client_id, and, for Auth0 and Okta, oidc.audience. Rebuild or remount the configuration.

  4. Bootstrap the first administrator: admin.default_root_email works when the access token carries email and email_verified: true (Keycloak); for Entra ID, Auth0, and Okta, run the documented SQL grant after the user’s first login.

  5. Manage every other user from the admin panel’s Users tab. New users arrive as developer with no panel role.

The core validates tokens against the issuer’s JWKS on every request and needs outbound access to the issuer’s discovery and JWKS endpoints. Access-token lifetime at the identity provider is the revocation latency: a user disabled at the identity provider keeps access until their access token expires (Kumoss has no user-disable switch of its own). Role changes made in the admin panel take effect on the user’s next request, because roles are read from the database on every request.

Project-level authorization

Decide whether users may operate on any cloud project their credentials reach, or whether Kumoss must ask your entitlement system first. In the second case, implement the authorization contract as described in Authorization (optional, must be replaced if enabled) and enable services.authz. Remember that this check runs in the wizard’s preflight; the IaC sidecar’s cloud identity is what ultimately bounds what can be changed.

LLM credentials

Choose the provider and models in config.yaml and supply the credentials as secrets to the core. Read Startup credential validation and its limits: some providers are not validated at boot, and custom variable names in llm.model_list still require the provider’s default variables to be present. Every prompt, including repository file contents the agent reads, is sent to the provider; choose an endpoint and data-handling terms accordingly. The core needs outbound HTTPS to the provider.

Git credentials

GIT_USER and GIT_TOKEN are written to ~/.git-credentials inside the core container at boot and used for every push, pull-request creation, and merge. Use a dedicated service account, restrict the token to the repositories Kumoss may change, and set git.provider to the matching host (GITHUB, AZURE_DEVOPS, or GITLAB). The core needs outbound HTTPS to the Git host, and HTTPS is the only transport: repository URLs must be https:// — SSH (git@host:path, ssh://), git://, http://, file:// and local paths are rejected with 422, so mounted SSH keys are never used. Repository URLs entered by users must not embed a password or token (https://user:<secret>@host/…​, and https://user:@host/…​ too); the API rejects those with 422. A bare userinfo username is accepted and kept as typed, so the <org>@ prefix that the Azure DevOps portal’s clone URL carries can be pasted as-is — but git then looks up the stored credential under that username, so it must match GIT_USER or authentication fails at clone time.

Supported hosts. The pull-request adapters target the public SaaS hosts only: github.com, gitlab.com (top-level namespace and project; subgroups are rejected), and dev.azure.com. GitHub Enterprise Server, self-managed GitLab, and *.visualstudio.com URLs are not supported today and fail at pull-request time with Malformed repository URL. Pull-request creation and merge always use the REST API over HTTPS with GIT_TOKEN.

Error messages. Every failure to reach or read the repository — git ls-remote when a URL is entered, the default-branch and branch-existence lookups, and clones — answers the fixed message "Repository is not reachable or access was denied.". Git’s own output, which can name internal hosts, addresses or proxy errors, is written only to the core log.

Cloud credentials for the IaC engine

Separate from the LLM and storage credentials. Give the IaC sidecar an identity that can read and change exactly the resources Kumoss manages, per cloud:

Cloud Recommended Static alternative in the sample file

Azure

Workload identity federation or managed identity for the azurerm provider

ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_TENANT_ID, ARM_SUBSCRIPTION_ID

Google Cloud

Workload identity

GOOGLE_CREDENTIALS (key JSON) or GOOGLE_APPLICATION_CREDENTIALS (mounted key file)

AWS

IAM role for the pod or instance

AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION

Oracle Cloud, Kubernetes

The provider’s own mechanisms (configuration file, instance principals, mounted kubeconfig)

none in the sample

That identity covers the resources. The state backend is a second grant on a different resource and must be satisfied on the same sidecar: init authenticates to the state store before any provider is configured, so an identity that can create infrastructure but cannot read state fails at the first command. The two often share variables — an s3 backend and the aws provider both read AWS_ACCESS_KEY_ID — but the state store commonly lives in another account, subscription, or project, and some backends read variables the providers ignore (ARM_ACCESS_KEY, ARM_SAS_TOKEN, GOOGLE_BACKEND_CREDENTIALS) precisely so the identities can differ. Minimums for both: Terraform providers; the rationale: Two sets of credentials on the sidecar.

The apply step runs with -auto-approve against the plan a human reviewed; there is no second confirmation inside the engine. The human gates are the pull-request review, the session lock, and the explicit apply action (Comparing the operating modes).