Skip to content

Security: LeiterConsulting/constellation

SECURITY.md

Security and data handling

Report and extension references

Report preview resolution reads an exact app/name using the authenticated caller. It runs permitted SPL in the existing bounded current-user search jobs, never as the report owner or through a scheduled job's credentials. Read-only commands, tokens, scope/populations and result limits still apply. Native Studio output retains its reference and normal report execution policy; the preview explicitly labels that difference. Original report definitions are not changed.

Explicit Environment checks can read accessible visualization configuration metadata. Only bounded app/name/framework fields are returned. Descriptions, search fragments and extension code are not fetched or executed. Discovery alone does not authorize renderer registration or prove extension safety/compatibility.

Reporting a vulnerability

Use GitHub's Report a vulnerability form when private vulnerability reporting is enabled. Maintainers must enable and check it when making the repository public; see the publication handoff. If it is unavailable, contact the repository maintainers privately; if necessary, open a minimal issue requesting a private reporting channel without vulnerability details or sensitive attachments. Do not include credentials, indexed data, user documents or exploit details in public issues.

The current 1.x line receives compatible bug and security fixes under the support policy. No response-time or production SLA is promised. Older preview branches are not separately maintained. Independent review is follow-up work; automated and native permission checks remain release requirements.

Trust and authority

Constellation's main and control handlers use the current user's session, roles and object access without system authentication. Two separate handlers receive system authentication: opt-in shared AITK inference and owner-only OpenAI key custody, as described below. The app does not grant roles. Discovery and search visibility are distinct. Two standard-role accounts have passed selected private draft, settings and native-view isolation checks; this does not qualify every role or deployment topology. Retrieved guidance, model output, reference documents and indexed content are untrusted; they cannot grant additional execution authority.

Provider output is parsed as structured edits and validated before atomic application. The app rejects unsupported code/properties, unresolved unsafe query tokens and commands outside its bounded read-only preview subset. These checks reduce risk; they are not a formal sandbox or a guarantee of analytical correctness. Broader permission, isolation and deployment qualification remains open.

Credentials

Direct-provider keys are configured through the installed Settings interface and stored in Splunk's encrypted credential store using per-user IDs, app scope, owner/app checks and empty read/write role grants. The backend does not return saved keys to the form or store them in browser storage. Splunk administrators retain credential-management authority. New/replacement key entry requires HTTPS, except for loopback development origins. New credentials start as empty placeholders; owner-only ACLs are verified before the real key is written. A separate owner-only handler performs encrypted storage operations under system authentication after verifying the real caller and deriving the credential path exclusively from that identity. Ordinary authors receive no credential-store capabilities. The main handler sees saved-key presence metadata, not saved keys.

Secretless Ollama/AITK connections use private per-user configuration and do not need password-store writes. A strict field allowlist rejects API keys and secret fields there. Existing configurations containing OpenAI keys remain encrypted; switching to an encrypted connection clears its obsolete secretless preference after the encrypted write succeeds. Administrators retain their platform authority over both stores.

AITK retains custody of its own credentials. Ollama receives its own configured origin/model, not an OpenAI key. Outbound direct-provider requests verify TLS where required and reject redirects; the Ollama route also rejects unsafe origin/address categories. Use normal trusted certificate, firewall and provider controls. Constellation is not a replacement for an organizational egress policy.

For shared AITK inference, an administrator may opt in to a dedicated Splunk REST handler using the platform's system authentication. This explicitly introduces a privileged inference boundary inside the app. It does not grant authors storage-password permissions or place provider keys in Constellation. The administrator-only policy pins the connection/execution namespace and permitted roles. A separate metadata guard checks the modern connection owner/write ACL and both backing KV collection ACLs, rejects legacy name shadowing and unsupported indirect-provider resolution, and does not call credential-store endpoints during preflight. The endpoint rechecks the caller's real identity/capability/role, accepts bounded text only, percent-encodes it into a constant synthetic SPL pipeline and returns only the completion. It cannot proxy arbitrary searches, credentials, URLs or job IDs. Main/control REST handlers never receive the system token; actual data validation and persistence retain caller authority. The privileged job is cancelled/deleted on exit; native audit/search history can still retain prompt-bearing records. Admission slots bound accepted requests per search head; they are not a strict quota on native jobs after an uncertain dispatch, infrastructure stall or process failure. Native REST transports have explicit timeouts. Concurrency controls are per search head; distributed quotas, load-balanced cancellation and Cloud acceptance remain separate gates. Review this code and its configuration as a privileged component before enabling it. See setup.

The owner-only OpenAI handler accepts private connection settings and fixed model-discovery/structured-response operations. It verifies caller identity and search authority, derives the exact owner/credential ID internally, checks existing ACLs before reading or updating a key, and validates the empty placeholder's restricted ACL before first key storage. No caller may supply an owner, path, URL or arbitrary provider operation. Existing encrypted records and owned legacy IDs remain in place. Public metadata carries a key-presence boolean; saved keys never return through either handler API. Fixed official HTTPS transport, no redirects, store:false, configured-model matching, token/request bounds and repeated inline-file/model guards apply. Tools, remote files/URLs and provider-side conversation references are not accepted. Ordinary authors remain denied direct password-store access, including their own record. Upstream inference may finish after Stop; admission and cleanup retain the limits described above. This privileged boundary requires deployment review too.

Provider data flow

Prompts, recent conversation, dashboard definitions and SPL, selected-element context and field metadata can be sent to the configured provider. Supported attachments submitted with a message are sent as well. Search-result rows are excluded from model context and remain in Splunk/browser previews. User-authored prompts, queries, documents and definitions can themselves contain confidential data; review them and the provider's retention/account policies before transmission.

Direct OpenAI uses store: false; that setting does not establish zero retention across every system. AITK uses prompt-bearing synthetic search jobs with normal Splunk history/retention behavior. Provider errors are reduced to controlled diagnostics instead of forwarding raw bodies. Stop discards late app edits but cannot guarantee upstream inference cancellation or avoid provider charges.

Drafts and retention

Private Splunk-backed drafts retain definitions, conversations, composer state, selected data/filter/page context and pending attachments. Search-result caches and provider keys are outside draft snapshots. Treat pending attachments and conversation history as sensitive stored content. Deleting a draft or managed private native view uses recoverable Trash, which retains content until handled through the supported lifecycle; it does not immediately erase it. Infrastructure backup and retention policies remain the administrator's responsibility.

While changes await a confirmed save, the app keeps one bounded recovery copy in this tab's sessionStorage. It can contain draft definitions/SPL, conversation, tokens and small pending attachments, and is sensitive browser content accessible to trusted scripts on the same Splunk origin. It contains no connection settings, saved provider keys or search-result cache. Startup first obtains the authenticated Splunk owner; mismatched-account, malformed/expired and deleted/unavailable records are discarded. Exact issued-state/revision proof is required before reconciling an old in-flight save; other conflicts preserve local work without overwriting the server.

Version 1.0.1 stores optional save receipts beside the private draft snapshot. They contain an operation ID, base/committed revisions and a canonical state digest. Save-error details expose only the stage, revisions and operation ID, not draft contents, credentials or search results.

The copy clears after confirmed save and expires after six hours. Closing the tab normally ends its storage session; browser restore/retention policies still apply. It is not a secure-erasure or durable-backup guarantee. Snapshots above 1.5 million JSON characters, storage denial/quota or eviction retain the wait-until-saved warning instead of claiming refresh protection. See browser storage behavior.

Revision checks and local locks protect one search head. Cross-member SHC write coordination is not qualified. Private links identify records and focus but require normal access; they are not public sharing tokens.

Repository and release controls

Live lab evidence, environment-specific automation, local configuration, credentials, certificates and build outputs are excluded from Git. Publication checks reject forbidden paths/private identifiers, and Gitleaks scans the staged content/history. Review binary fixtures and commit metadata too. Automated scans do not guarantee the absence of every secret or vulnerability.

Do not force-add ignored operational material, broadly disable a detector or use a real key as a test fixture. If a real secret is exposed, stop publication and follow the owner's credential incident process; removing a file from the latest commit alone does not remove it from history.

AppInspect precert, unit tests and selected live flows are separate evidence from a security audit, production qualification or Splunk Cloud certification. See validation.

Validated authoring replies can temporarily remain in private search-head-local delivery files for recovery of a lost REST response. They may include dashboard definitions/SPL, the user-authored brief/goal and normal metadata. The original session-signed handle is required; another user/session cannot retrieve them. Access expires after five minutes. Acknowledgement/Stop deletes replies, and later control activity cleans expired files; there is no idle background deletion timer. Storage is bounded and mode 0700/0600. This adds no system authentication or credential access. See architecture.

Shared artwork and portable files

Native Studio image/icon collections retain their platform ACLs. Uploads run as the current user, require their native write permission and are readable under the shared collection policy even on private dashboards. Constellation adds no upload proxy or elevated media handler. Its upload/import paths validate passive SVG markup, raster signatures, size and encoding, then verify stored bytes. Unsupported SVG is rejected rather than silently sanitized. Imported native documents keep their original bytes; the bounded preview can decline unsupported media.

Portable files contain dashboard definitions and selected shared artwork, including potentially sensitive searches or filenames. They exclude conversations, runtime preview snapshots and provider settings; an imported definition can already contain embedded data. Review them before sharing. SHA-256 checks detect corruption, not authorship or trust. All assets are preflighted before writes and new destination records are created; exact known slots are remapped without general string replacement. Partial or uncertain writes are reported and never automatically replayed or removed from shared libraries. Keep referenced reports, lookups, packaged/external files and destination data access under their normal review.

There aren't any published security advisories