[PR] Add Polaris threat model and security guidance for agents [polaris]

["snazy (via GitHub)" <gi...@apache.org>]

snazy opened a new pull request, #4433:
URL: https://github.com/apache/polaris/pull/4433

   This adds an initial `SECURITY-THREAT-MODEL.md` and links it from `AGENTS.md`.
   
   The goal is to give human reviewers and automated coding/security agents a shared description of Polaris security boundaries, protected assets, trust boundaries, non-issues, and reporting expectations.
   
   This is intended as analysis and triage guidance only. It does not change the project security policy, define ASF severity, decide CVE/advisory handling, or replace `SECURITY.md` or the public security reporting page.
   
   I kept the first version broad on purpose. Follow-up PRs can refine individual sections if reviewers think some areas need more detail or different wording.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["snazy (via GitHub)" <gi...@apache.org>]

snazy commented on PR #4433:
URL: https://github.com/apache/polaris/pull/4433#issuecomment-4516695471

   Agree, I shortened `AGENTS.md` to point at the threat model and keep only the non-negotiable handling rules there. The detailed category/variant guidance remains in `SECURITY-THREAT-MODEL.md`, where it is easier to keep aligned with the code.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["RussellSpitzer (via GitHub)" <gi...@apache.org>]

RussellSpitzer commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3244439447


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal
+  authorized for one logical entity to access another logical entity's data or
+  metadata.
+- Provider policy documents and expressions must escape or otherwise safely
+  encode caller-controlled identifiers, paths, and property values.
+- User-controlled input must not be used to construct SQL, filesystem paths,
+  object-store paths, URLs, or process commands without appropriate validation or
+  safe APIs.
+- Error messages must not disclose secrets or unauthorized metadata.
+- Existence, names, and relationships of principals, roles, catalogs,
+  namespaces, tables, views, and policies must not be disclosed to unauthorized
+  callers unless that disclosure is explicitly documented and accepted.
+- Configuration changes that create, reset, rotate, store, or delete credentials
+  or secrets must be authorized, consistently applied, and must not leave stale
+  credentials or orphaned secrets with unintended access.
+- Internal and administrative APIs must not be exposed as public unauthenticated
+  APIs.
+- Optional build features, extensions, and distribution-specific packaging must
+  not weaken Polaris authentication, authorization, credential handling, or
+  metadata isolation without explicit configuration and documentation.
+
+## Security Issues
+
+The following should generally be treated as potential security vulnerabilities:
+
+- Authentication bypass.
+- Authorization bypass or privilege escalation.
+- Cross-catalog or cross-realm data access caused by missing checks.
+- Unauthorized mutation of catalog metadata, roles, policies, or principals.
+- Exposure of credentials, tokens, secrets, or sensitive configuration.
+- Exposure of secrets through client-visible properties, configuration
+  responses, logs, profiles, command output, browser storage, or generated
+  artifacts.
+- Credential-vending behavior that grants broader storage access than the
+  caller's authorized operation or effective storage boundary.
+- Storage-location validation bypasses, including unvalidated URI-bearing table
+  metadata, reused or overlapping locations, and provider-policy construction
+  issues.
+- Token or credential lifecycle issues that allow access to continue beyond the
+  intended reset, rotation, revocation, realm, or scope boundary.
+- Unauthorized disclosure of identity, role, policy, catalog, namespace, table,
+  or view existence when that existence is itself sensitive.
+- SQL injection, command injection, unsafe deserialization, server-side request
+  forgery, path traversal, or template injection reachable through untrusted
+  input.
+- Unsafe use of externally configured endpoints that can redirect privileged
+  traffic, credentials, tokens, metadata, or storage requests outside the
+  intended trust relationship.
+- Logging or returning sensitive values to unauthorized users.
+- Use of weak cryptographic validation for authentication or authorization
+  decisions.
+- Insecure defaults that expose protected APIs or disable required security
+  checks.
+
+## Non-Issues And Deployment Responsibilities
+
+The following are not normally treated as Polaris vulnerabilities by themselves:
+
+- A deployment operator choosing weak credentials or exposing the service
+  publicly without required network controls.
+- A compromised administrator using their legitimate administrative privileges.
+- A compromised database, object store, Kubernetes cluster, host operating
+  system, identity provider, or external policy decision point.
+- Lack of rate limiting unless it enables a concrete security impact beyond
+  resource exhaustion.
+- Information visible to a principal that is explicitly authorized to access it.
+- Storage-provider limitations that are accurately documented and do not give
+  Polaris callers more access than the deployment intentionally configured.
+- Test-only code, local development defaults, or example configuration not used
+  in production paths, unless clearly reachable in production builds.
+
+Polaris does not, by itself, provide the following security properties:
+
+- Protection after compromise of deployment infrastructure, persistence
+  backends, object stores, identity providers, external policy decision points,
+  Kubernetes clusters, hosts, or administrator workstations.
+- Protection against authorized administrators using their legitimate privileges
+  in ways the deployment does not intend.
+- Network isolation, TLS termination, firewalling, ingress policy, Kubernetes
+  policy, or cloud-account isolation beyond what the deployment provides.
+- Secret management for values that operators place outside Polaris-controlled
+  secret storage or configuration mechanisms.
+- Stronger delegated-credential isolation than the selected storage provider,
+  configured policy model, and documented deployment mode can support.
+- Safety of arbitrary downstream packaging, module combinations, integrations,
+  or local patches that are not part of an official Polaris artifact or
+  documented supported configuration.
+
+Deployment operators and downstream integrators are responsible for:
+
+- Protecting service credentials, signing keys, client secrets, object-store
+  credentials, identity-provider configuration, policy-service credentials, and
+  local CLI or admin-tool profiles.
+- Configuring TLS, network exposure, ingress, firewalls, service accounts,
+  Kubernetes permissions, cloud IAM, object-store policy, and persistence-backend
+  access according to the deployment's security requirements.
+- Choosing production-appropriate authentication, authorization, persistence,
+  storage, and policy-service settings before exposing Polaris to untrusted
+  clients.
+- Avoiding production use of local-development defaults, sample credentials,
+  test fixtures, example configuration, and benchmark-only tooling unless those
+  choices are explicitly intended and protected.
+- Rotating and revoking credentials, tokens, secrets, and delegated access
+  according to the deployment's operational requirements.
+- Protecting logs, generated configuration, local profiles, backups, database
+  snapshots, object-store metadata, and other artifacts that may contain
+  security-sensitive values.
+
+The following patterns often require careful triage because they can be
+vulnerabilities, documentation hardening items, deployment responsibilities, or
+false positives depending on the actor, configuration, and reachable path:
+
+- Treating client-visible properties, catalog metadata, generated configuration,
+  local profiles, command output, browser storage, or logs as secret stores.
+- Assuming delegated storage credentials are narrower than the configured
+  provider policy, access-boundary mechanism, or documented deployment mode
+  actually supports.
+- Assuming every custom build, Gradle project combination, optional dependency,
+  extension, or downstream package is an official supported Polaris artifact.
+- Applying server threat-model assumptions unchanged to CLIs, web UIs,
+  migration tools, MCP servers, synchronization tools, benchmarks, or other
+  related tools.
+- Treating test fixtures, mocked trust decisions, direct internal object
+  construction, or already-authorized access as proof of a production
+  vulnerability.
+- Treating dependency advisories as Polaris vulnerabilities without showing that
+  the vulnerable behavior is present, reachable, and crosses a Polaris trust
+  boundary.
+
+Known non-findings are cases already covered by the non-issues, dependency,
+variant, distribution, and related-tool sections above. Common examples include
+authorized access, unreachable dependency advisories, test-only behavior,
+compromised deployment infrastructure, and impossible variant combinations.
+
+## Consumption And Distribution Boundaries
+
+Users consume Polaris in several ways, including:
+
+- Release tarballs containing the runnable Quarkus applications for the Polaris
+  server and Polaris admin tool.
+- Container images for the Polaris server and Polaris admin tool.
+- Helm charts for deploying the Polaris server.
+- The Python-based CLI tool under `client/`.
+- Custom applications or distributions built from Polaris modules such as
+  `polaris-core`, `polaris-runtime-service`, extension modules, or other Gradle
+  project combinations.
+
+The Polaris threat model applies directly to artifacts and modules produced by
+the Apache Polaris project. It also applies to custom distributions when they use
+Polaris code to make authentication, authorization, catalog metadata, policy, or
+credential-handling decisions.
+
+Custom distributions can change the effective threat model. When evaluating a
+finding, determine whether the behavior is present in:
+
+- An official Polaris release artifact.
+- An official Polaris container image.
+- An official Polaris Helm chart.
+- The Polaris CLI.
+- A reusable Polaris module.

Review Comment:
   Does this mean every production module we push to maven? (Exclude tests + docs)



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["flyingImer (via GitHub)" <gi...@apache.org>]

flyingImer commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3270066598


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,740 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata whose visibility is governed by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but persistence-layer
+  access by internal Polaris callsites is not by itself proof that the data may be
+  returned to an external caller or used to mutate protected state. Authorization
+  must be enforced before protected data is exposed or protected state is changed.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- Grant and role-management operations must enforce the intended grant authority
+  defined by Polaris authorization rules. A principal must not be able to obtain
+  privileges that direct checks would reject by using indirect role creation,
+  self-grants, role nesting, privilege delegation, or other second-order effects.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Within the applicable realm and configured storage-policy scope, reused,
+  overlapping, or ambiguous storage locations must not create an unintended
+  authorization bypass. Explicitly configured overlap modes, table clones, and
+  documented credential-vending scope limitations should be treated according to
+  their documented behavior, not reported solely because overlap exists.

Review Comment:
   +1 to dennis. As written, agents will file false-positive findings against intentional overlap-check overrides, table clones, legitimate role nesting (line 179), and internal-callsite reads that don't return data externally (line 161-164). My bias would be to land all three clarifications in this PR. Once AGENTS.md cites the model the broad invariants become the default rule, and the project can't reclassify findings already filed.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["RussellSpitzer (via GitHub)" <gi...@apache.org>]

RussellSpitzer commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3244433625


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal
+  authorized for one logical entity to access another logical entity's data or
+  metadata.
+- Provider policy documents and expressions must escape or otherwise safely
+  encode caller-controlled identifiers, paths, and property values.
+- User-controlled input must not be used to construct SQL, filesystem paths,
+  object-store paths, URLs, or process commands without appropriate validation or
+  safe APIs.
+- Error messages must not disclose secrets or unauthorized metadata.
+- Existence, names, and relationships of principals, roles, catalogs,
+  namespaces, tables, views, and policies must not be disclosed to unauthorized
+  callers unless that disclosure is explicitly documented and accepted.
+- Configuration changes that create, reset, rotate, store, or delete credentials
+  or secrets must be authorized, consistently applied, and must not leave stale
+  credentials or orphaned secrets with unintended access.
+- Internal and administrative APIs must not be exposed as public unauthenticated
+  APIs.
+- Optional build features, extensions, and distribution-specific packaging must
+  not weaken Polaris authentication, authorization, credential handling, or
+  metadata isolation without explicit configuration and documentation.
+
+## Security Issues
+
+The following should generally be treated as potential security vulnerabilities:
+
+- Authentication bypass.
+- Authorization bypass or privilege escalation.
+- Cross-catalog or cross-realm data access caused by missing checks.
+- Unauthorized mutation of catalog metadata, roles, policies, or principals.
+- Exposure of credentials, tokens, secrets, or sensitive configuration.
+- Exposure of secrets through client-visible properties, configuration
+  responses, logs, profiles, command output, browser storage, or generated
+  artifacts.
+- Credential-vending behavior that grants broader storage access than the
+  caller's authorized operation or effective storage boundary.
+- Storage-location validation bypasses, including unvalidated URI-bearing table
+  metadata, reused or overlapping locations, and provider-policy construction
+  issues.
+- Token or credential lifecycle issues that allow access to continue beyond the
+  intended reset, rotation, revocation, realm, or scope boundary.
+- Unauthorized disclosure of identity, role, policy, catalog, namespace, table,
+  or view existence when that existence is itself sensitive.
+- SQL injection, command injection, unsafe deserialization, server-side request
+  forgery, path traversal, or template injection reachable through untrusted
+  input.
+- Unsafe use of externally configured endpoints that can redirect privileged
+  traffic, credentials, tokens, metadata, or storage requests outside the
+  intended trust relationship.
+- Logging or returning sensitive values to unauthorized users.
+- Use of weak cryptographic validation for authentication or authorization
+  decisions.
+- Insecure defaults that expose protected APIs or disable required security
+  checks.
+
+## Non-Issues And Deployment Responsibilities
+
+The following are not normally treated as Polaris vulnerabilities by themselves:
+
+- A deployment operator choosing weak credentials or exposing the service
+  publicly without required network controls.
+- A compromised administrator using their legitimate administrative privileges.
+- A compromised database, object store, Kubernetes cluster, host operating
+  system, identity provider, or external policy decision point.
+- Lack of rate limiting unless it enables a concrete security impact beyond
+  resource exhaustion.
+- Information visible to a principal that is explicitly authorized to access it.
+- Storage-provider limitations that are accurately documented and do not give
+  Polaris callers more access than the deployment intentionally configured.
+- Test-only code, local development defaults, or example configuration not used
+  in production paths, unless clearly reachable in production builds.
+
+Polaris does not, by itself, provide the following security properties:
+
+- Protection after compromise of deployment infrastructure, persistence
+  backends, object stores, identity providers, external policy decision points,
+  Kubernetes clusters, hosts, or administrator workstations.
+- Protection against authorized administrators using their legitimate privileges
+  in ways the deployment does not intend.
+- Network isolation, TLS termination, firewalling, ingress policy, Kubernetes
+  policy, or cloud-account isolation beyond what the deployment provides.
+- Secret management for values that operators place outside Polaris-controlled
+  secret storage or configuration mechanisms.
+- Stronger delegated-credential isolation than the selected storage provider,
+  configured policy model, and documented deployment mode can support.
+- Safety of arbitrary downstream packaging, module combinations, integrations,
+  or local patches that are not part of an official Polaris artifact or
+  documented supported configuration.
+
+Deployment operators and downstream integrators are responsible for:
+
+- Protecting service credentials, signing keys, client secrets, object-store
+  credentials, identity-provider configuration, policy-service credentials, and
+  local CLI or admin-tool profiles.
+- Configuring TLS, network exposure, ingress, firewalls, service accounts,
+  Kubernetes permissions, cloud IAM, object-store policy, and persistence-backend
+  access according to the deployment's security requirements.
+- Choosing production-appropriate authentication, authorization, persistence,
+  storage, and policy-service settings before exposing Polaris to untrusted
+  clients.
+- Avoiding production use of local-development defaults, sample credentials,
+  test fixtures, example configuration, and benchmark-only tooling unless those
+  choices are explicitly intended and protected.
+- Rotating and revoking credentials, tokens, secrets, and delegated access
+  according to the deployment's operational requirements.
+- Protecting logs, generated configuration, local profiles, backups, database
+  snapshots, object-store metadata, and other artifacts that may contain
+  security-sensitive values.
+
+The following patterns often require careful triage because they can be
+vulnerabilities, documentation hardening items, deployment responsibilities, or
+false positives depending on the actor, configuration, and reachable path:
+
+- Treating client-visible properties, catalog metadata, generated configuration,
+  local profiles, command output, browser storage, or logs as secret stores.
+- Assuming delegated storage credentials are narrower than the configured
+  provider policy, access-boundary mechanism, or documented deployment mode
+  actually supports.
+- Assuming every custom build, Gradle project combination, optional dependency,
+  extension, or downstream package is an official supported Polaris artifact.
+- Applying server threat-model assumptions unchanged to CLIs, web UIs,
+  migration tools, MCP servers, synchronization tools, benchmarks, or other
+  related tools.
+- Treating test fixtures, mocked trust decisions, direct internal object
+  construction, or already-authorized access as proof of a production
+  vulnerability.
+- Treating dependency advisories as Polaris vulnerabilities without showing that
+  the vulnerable behavior is present, reachable, and crosses a Polaris trust
+  boundary.
+
+Known non-findings are cases already covered by the non-issues, dependency,
+variant, distribution, and related-tool sections above. Common examples include
+authorized access, unreachable dependency advisories, test-only behavior,
+compromised deployment infrastructure, and impossible variant combinations.
+
+## Consumption And Distribution Boundaries
+
+Users consume Polaris in several ways, including:
+
+- Release tarballs containing the runnable Quarkus applications for the Polaris
+  server and Polaris admin tool.
+- Container images for the Polaris server and Polaris admin tool.
+- Helm charts for deploying the Polaris server.
+- The Python-based CLI tool under `client/`.
+- Custom applications or distributions built from Polaris modules such as
+  `polaris-core`, `polaris-runtime-service`, extension modules, or other Gradle
+  project combinations.
+
+The Polaris threat model applies directly to artifacts and modules produced by
+the Apache Polaris project. It also applies to custom distributions when they use
+Polaris code to make authentication, authorization, catalog metadata, policy, or
+credential-handling decisions.
+
+Custom distributions can change the effective threat model. When evaluating a
+finding, determine whether the behavior is present in:
+
+- An official Polaris release artifact.

Review Comment:
   Not sure if this covers "official source release + documented build", I think it should be enough 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["RussellSpitzer (via GitHub)" <gi...@apache.org>]

RussellSpitzer commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3244450580


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal
+  authorized for one logical entity to access another logical entity's data or
+  metadata.
+- Provider policy documents and expressions must escape or otherwise safely
+  encode caller-controlled identifiers, paths, and property values.
+- User-controlled input must not be used to construct SQL, filesystem paths,
+  object-store paths, URLs, or process commands without appropriate validation or
+  safe APIs.
+- Error messages must not disclose secrets or unauthorized metadata.
+- Existence, names, and relationships of principals, roles, catalogs,
+  namespaces, tables, views, and policies must not be disclosed to unauthorized
+  callers unless that disclosure is explicitly documented and accepted.
+- Configuration changes that create, reset, rotate, store, or delete credentials
+  or secrets must be authorized, consistently applied, and must not leave stale
+  credentials or orphaned secrets with unintended access.
+- Internal and administrative APIs must not be exposed as public unauthenticated
+  APIs.
+- Optional build features, extensions, and distribution-specific packaging must
+  not weaken Polaris authentication, authorization, credential handling, or
+  metadata isolation without explicit configuration and documentation.
+
+## Security Issues
+
+The following should generally be treated as potential security vulnerabilities:
+
+- Authentication bypass.
+- Authorization bypass or privilege escalation.
+- Cross-catalog or cross-realm data access caused by missing checks.
+- Unauthorized mutation of catalog metadata, roles, policies, or principals.
+- Exposure of credentials, tokens, secrets, or sensitive configuration.
+- Exposure of secrets through client-visible properties, configuration
+  responses, logs, profiles, command output, browser storage, or generated
+  artifacts.
+- Credential-vending behavior that grants broader storage access than the
+  caller's authorized operation or effective storage boundary.
+- Storage-location validation bypasses, including unvalidated URI-bearing table
+  metadata, reused or overlapping locations, and provider-policy construction
+  issues.
+- Token or credential lifecycle issues that allow access to continue beyond the
+  intended reset, rotation, revocation, realm, or scope boundary.
+- Unauthorized disclosure of identity, role, policy, catalog, namespace, table,
+  or view existence when that existence is itself sensitive.
+- SQL injection, command injection, unsafe deserialization, server-side request
+  forgery, path traversal, or template injection reachable through untrusted
+  input.
+- Unsafe use of externally configured endpoints that can redirect privileged
+  traffic, credentials, tokens, metadata, or storage requests outside the
+  intended trust relationship.
+- Logging or returning sensitive values to unauthorized users.
+- Use of weak cryptographic validation for authentication or authorization
+  decisions.
+- Insecure defaults that expose protected APIs or disable required security
+  checks.
+
+## Non-Issues And Deployment Responsibilities
+
+The following are not normally treated as Polaris vulnerabilities by themselves:
+
+- A deployment operator choosing weak credentials or exposing the service
+  publicly without required network controls.
+- A compromised administrator using their legitimate administrative privileges.
+- A compromised database, object store, Kubernetes cluster, host operating
+  system, identity provider, or external policy decision point.
+- Lack of rate limiting unless it enables a concrete security impact beyond
+  resource exhaustion.
+- Information visible to a principal that is explicitly authorized to access it.
+- Storage-provider limitations that are accurately documented and do not give
+  Polaris callers more access than the deployment intentionally configured.
+- Test-only code, local development defaults, or example configuration not used
+  in production paths, unless clearly reachable in production builds.
+
+Polaris does not, by itself, provide the following security properties:
+
+- Protection after compromise of deployment infrastructure, persistence
+  backends, object stores, identity providers, external policy decision points,
+  Kubernetes clusters, hosts, or administrator workstations.
+- Protection against authorized administrators using their legitimate privileges
+  in ways the deployment does not intend.
+- Network isolation, TLS termination, firewalling, ingress policy, Kubernetes
+  policy, or cloud-account isolation beyond what the deployment provides.
+- Secret management for values that operators place outside Polaris-controlled
+  secret storage or configuration mechanisms.
+- Stronger delegated-credential isolation than the selected storage provider,
+  configured policy model, and documented deployment mode can support.
+- Safety of arbitrary downstream packaging, module combinations, integrations,
+  or local patches that are not part of an official Polaris artifact or
+  documented supported configuration.
+
+Deployment operators and downstream integrators are responsible for:
+
+- Protecting service credentials, signing keys, client secrets, object-store
+  credentials, identity-provider configuration, policy-service credentials, and
+  local CLI or admin-tool profiles.
+- Configuring TLS, network exposure, ingress, firewalls, service accounts,
+  Kubernetes permissions, cloud IAM, object-store policy, and persistence-backend
+  access according to the deployment's security requirements.
+- Choosing production-appropriate authentication, authorization, persistence,
+  storage, and policy-service settings before exposing Polaris to untrusted
+  clients.
+- Avoiding production use of local-development defaults, sample credentials,
+  test fixtures, example configuration, and benchmark-only tooling unless those
+  choices are explicitly intended and protected.
+- Rotating and revoking credentials, tokens, secrets, and delegated access
+  according to the deployment's operational requirements.
+- Protecting logs, generated configuration, local profiles, backups, database
+  snapshots, object-store metadata, and other artifacts that may contain
+  security-sensitive values.
+
+The following patterns often require careful triage because they can be
+vulnerabilities, documentation hardening items, deployment responsibilities, or
+false positives depending on the actor, configuration, and reachable path:
+
+- Treating client-visible properties, catalog metadata, generated configuration,
+  local profiles, command output, browser storage, or logs as secret stores.
+- Assuming delegated storage credentials are narrower than the configured
+  provider policy, access-boundary mechanism, or documented deployment mode
+  actually supports.
+- Assuming every custom build, Gradle project combination, optional dependency,
+  extension, or downstream package is an official supported Polaris artifact.
+- Applying server threat-model assumptions unchanged to CLIs, web UIs,
+  migration tools, MCP servers, synchronization tools, benchmarks, or other
+  related tools.
+- Treating test fixtures, mocked trust decisions, direct internal object
+  construction, or already-authorized access as proof of a production
+  vulnerability.
+- Treating dependency advisories as Polaris vulnerabilities without showing that
+  the vulnerable behavior is present, reachable, and crosses a Polaris trust
+  boundary.
+
+Known non-findings are cases already covered by the non-issues, dependency,
+variant, distribution, and related-tool sections above. Common examples include
+authorized access, unreachable dependency advisories, test-only behavior,
+compromised deployment infrastructure, and impossible variant combinations.
+
+## Consumption And Distribution Boundaries
+
+Users consume Polaris in several ways, including:
+
+- Release tarballs containing the runnable Quarkus applications for the Polaris
+  server and Polaris admin tool.
+- Container images for the Polaris server and Polaris admin tool.
+- Helm charts for deploying the Polaris server.
+- The Python-based CLI tool under `client/`.
+- Custom applications or distributions built from Polaris modules such as
+  `polaris-core`, `polaris-runtime-service`, extension modules, or other Gradle
+  project combinations.
+
+The Polaris threat model applies directly to artifacts and modules produced by
+the Apache Polaris project. It also applies to custom distributions when they use
+Polaris code to make authentication, authorization, catalog metadata, policy, or
+credential-handling decisions.
+
+Custom distributions can change the effective threat model. When evaluating a
+finding, determine whether the behavior is present in:
+
+- An official Polaris release artifact.
+- An official Polaris container image.
+- An official Polaris Helm chart.
+- The Polaris CLI.
+- A reusable Polaris module.
+- An optional extension or dependency enabled by build configuration.
+- Downstream-only integration code or deployment packaging.
+

Review Comment:
   I think all my previous questions are stipulated below, so I think this is good. Although i'm still not sure if reusable modules is too broad a category but hopefully an agent can make that judgement based off of SPI / API guarantees in the project



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["snazy (via GitHub)" <gi...@apache.org>]

snazy merged PR #4433:
URL: https://github.com/apache/polaris/pull/4433


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["jbonofre (via GitHub)" <gi...@apache.org>]

jbonofre commented on PR #4433:
URL: https://github.com/apache/polaris/pull/4433#issuecomment-4531868769

   @potiuk I'm doing a new review pass. I will merge tomorrow to give time to the team to take a last look.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["RussellSpitzer (via GitHub)" <gi...@apache.org>]

RussellSpitzer commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3244367546


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal

Review Comment:
   I do wonder if this is too broad? It's probably good to keep it for now and change it if we get any reports that are "User A can access B with B' access controls but they are also allowed to access B"
   
   Probably fine for now though.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["snazy (via GitHub)" <gi...@apache.org>]

snazy commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3246543638


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal

Review Comment:
   Okay, then let's maybe blame Claude when it does not handle it? ;) ;)



##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.

Review Comment:
   Yea, adjusted the wording.



##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal
+  authorized for one logical entity to access another logical entity's data or
+  metadata.
+- Provider policy documents and expressions must escape or otherwise safely
+  encode caller-controlled identifiers, paths, and property values.
+- User-controlled input must not be used to construct SQL, filesystem paths,
+  object-store paths, URLs, or process commands without appropriate validation or
+  safe APIs.
+- Error messages must not disclose secrets or unauthorized metadata.
+- Existence, names, and relationships of principals, roles, catalogs,
+  namespaces, tables, views, and policies must not be disclosed to unauthorized
+  callers unless that disclosure is explicitly documented and accepted.
+- Configuration changes that create, reset, rotate, store, or delete credentials
+  or secrets must be authorized, consistently applied, and must not leave stale
+  credentials or orphaned secrets with unintended access.
+- Internal and administrative APIs must not be exposed as public unauthenticated
+  APIs.
+- Optional build features, extensions, and distribution-specific packaging must
+  not weaken Polaris authentication, authorization, credential handling, or
+  metadata isolation without explicit configuration and documentation.
+
+## Security Issues
+
+The following should generally be treated as potential security vulnerabilities:
+
+- Authentication bypass.
+- Authorization bypass or privilege escalation.
+- Cross-catalog or cross-realm data access caused by missing checks.
+- Unauthorized mutation of catalog metadata, roles, policies, or principals.
+- Exposure of credentials, tokens, secrets, or sensitive configuration.
+- Exposure of secrets through client-visible properties, configuration
+  responses, logs, profiles, command output, browser storage, or generated
+  artifacts.
+- Credential-vending behavior that grants broader storage access than the
+  caller's authorized operation or effective storage boundary.
+- Storage-location validation bypasses, including unvalidated URI-bearing table
+  metadata, reused or overlapping locations, and provider-policy construction
+  issues.
+- Token or credential lifecycle issues that allow access to continue beyond the
+  intended reset, rotation, revocation, realm, or scope boundary.
+- Unauthorized disclosure of identity, role, policy, catalog, namespace, table,
+  or view existence when that existence is itself sensitive.
+- SQL injection, command injection, unsafe deserialization, server-side request
+  forgery, path traversal, or template injection reachable through untrusted
+  input.
+- Unsafe use of externally configured endpoints that can redirect privileged
+  traffic, credentials, tokens, metadata, or storage requests outside the
+  intended trust relationship.
+- Logging or returning sensitive values to unauthorized users.
+- Use of weak cryptographic validation for authentication or authorization
+  decisions.
+- Insecure defaults that expose protected APIs or disable required security
+  checks.
+
+## Non-Issues And Deployment Responsibilities
+
+The following are not normally treated as Polaris vulnerabilities by themselves:
+
+- A deployment operator choosing weak credentials or exposing the service
+  publicly without required network controls.
+- A compromised administrator using their legitimate administrative privileges.
+- A compromised database, object store, Kubernetes cluster, host operating
+  system, identity provider, or external policy decision point.
+- Lack of rate limiting unless it enables a concrete security impact beyond
+  resource exhaustion.
+- Information visible to a principal that is explicitly authorized to access it.
+- Storage-provider limitations that are accurately documented and do not give
+  Polaris callers more access than the deployment intentionally configured.
+- Test-only code, local development defaults, or example configuration not used
+  in production paths, unless clearly reachable in production builds.
+
+Polaris does not, by itself, provide the following security properties:
+
+- Protection after compromise of deployment infrastructure, persistence
+  backends, object stores, identity providers, external policy decision points,
+  Kubernetes clusters, hosts, or administrator workstations.
+- Protection against authorized administrators using their legitimate privileges
+  in ways the deployment does not intend.
+- Network isolation, TLS termination, firewalling, ingress policy, Kubernetes
+  policy, or cloud-account isolation beyond what the deployment provides.
+- Secret management for values that operators place outside Polaris-controlled
+  secret storage or configuration mechanisms.
+- Stronger delegated-credential isolation than the selected storage provider,
+  configured policy model, and documented deployment mode can support.
+- Safety of arbitrary downstream packaging, module combinations, integrations,
+  or local patches that are not part of an official Polaris artifact or
+  documented supported configuration.
+
+Deployment operators and downstream integrators are responsible for:
+
+- Protecting service credentials, signing keys, client secrets, object-store
+  credentials, identity-provider configuration, policy-service credentials, and
+  local CLI or admin-tool profiles.
+- Configuring TLS, network exposure, ingress, firewalls, service accounts,
+  Kubernetes permissions, cloud IAM, object-store policy, and persistence-backend
+  access according to the deployment's security requirements.
+- Choosing production-appropriate authentication, authorization, persistence,
+  storage, and policy-service settings before exposing Polaris to untrusted
+  clients.
+- Avoiding production use of local-development defaults, sample credentials,
+  test fixtures, example configuration, and benchmark-only tooling unless those
+  choices are explicitly intended and protected.
+- Rotating and revoking credentials, tokens, secrets, and delegated access
+  according to the deployment's operational requirements.
+- Protecting logs, generated configuration, local profiles, backups, database
+  snapshots, object-store metadata, and other artifacts that may contain
+  security-sensitive values.
+
+The following patterns often require careful triage because they can be
+vulnerabilities, documentation hardening items, deployment responsibilities, or
+false positives depending on the actor, configuration, and reachable path:
+
+- Treating client-visible properties, catalog metadata, generated configuration,
+  local profiles, command output, browser storage, or logs as secret stores.
+- Assuming delegated storage credentials are narrower than the configured
+  provider policy, access-boundary mechanism, or documented deployment mode
+  actually supports.
+- Assuming every custom build, Gradle project combination, optional dependency,
+  extension, or downstream package is an official supported Polaris artifact.
+- Applying server threat-model assumptions unchanged to CLIs, web UIs,
+  migration tools, MCP servers, synchronization tools, benchmarks, or other
+  related tools.
+- Treating test fixtures, mocked trust decisions, direct internal object
+  construction, or already-authorized access as proof of a production
+  vulnerability.
+- Treating dependency advisories as Polaris vulnerabilities without showing that
+  the vulnerable behavior is present, reachable, and crosses a Polaris trust
+  boundary.
+
+Known non-findings are cases already covered by the non-issues, dependency,
+variant, distribution, and related-tool sections above. Common examples include
+authorized access, unreachable dependency advisories, test-only behavior,
+compromised deployment infrastructure, and impossible variant combinations.
+
+## Consumption And Distribution Boundaries
+
+Users consume Polaris in several ways, including:
+
+- Release tarballs containing the runnable Quarkus applications for the Polaris
+  server and Polaris admin tool.
+- Container images for the Polaris server and Polaris admin tool.
+- Helm charts for deploying the Polaris server.
+- The Python-based CLI tool under `client/`.
+- Custom applications or distributions built from Polaris modules such as
+  `polaris-core`, `polaris-runtime-service`, extension modules, or other Gradle
+  project combinations.
+
+The Polaris threat model applies directly to artifacts and modules produced by
+the Apache Polaris project. It also applies to custom distributions when they use
+Polaris code to make authentication, authorization, catalog metadata, policy, or
+credential-handling decisions.
+
+Custom distributions can change the effective threat model. When evaluating a
+finding, determine whether the behavior is present in:
+
+- An official Polaris release artifact.
+- An official Polaris container image.
+- An official Polaris Helm chart.
+- The Polaris CLI.
+- A reusable Polaris module.
+- An optional extension or dependency enabled by build configuration.
+- Downstream-only integration code or deployment packaging.
+
+A finding in downstream-only code, private packaging, custom deployment
+configuration, or third-party integration logic is not automatically a Polaris
+vulnerability. Findings in custom distributions or downstream integrations may
+still be useful to report when they indicate a weakness in Polaris code,
+supported configuration, documented integration guidance, reusable modules,
+extension points, or official release artifacts. Such findings are evaluated case
+by case and are not automatically accepted as Polaris vulnerabilities.
+
+Building a custom distribution from an official Polaris source release can help
+establish that the affected code originates from Polaris, but it does not by
+itself make every selected module combination, optional dependency, Gradle
+property, packaging choice, or deployment configuration an official supported
+artifact.
+
+The severity and handling of a finding depend on the affected actor, protected
+asset, trust boundary, exploitability, default exposure, affected official
+artifacts, documented usage, and whether Polaris code or configuration is
+responsible for the security decision.
+
+Findings against unreleased code, including development branches such as `main`,
+may still be useful to report, but they are not automatically treated the same as
+findings affecting released Polaris artifacts. Handling depends on whether the
+issue affects released code, is likely to ship, or indicates a broader weakness
+in Polaris code, defaults, extension points, or documented guidance.
+
+## Backend And Authorization Variants
+
+Official Polaris artifacts may include multiple backend, authentication,
+authorization, storage, and extension implementations. Automated analysis should
+consider all implementations present in the artifact, but concrete findings must
+identify the coherent runtime configuration under which the behavior is
+reachable.
+
+The presence of multiple implementations in one artifact does not mean their
+runtime assumptions can be freely combined. Do not mix assumptions from
+different persistence backends, authentication modes, authorization services,
+storage providers, optional extensions, or deployment profiles unless the
+combination is supported and reachable in one deployment.
+
+Polaris behavior depends on configured persistence, authentication, and
+authorization components. Automated analysis must identify the active variant
+before assessing reachability, impact, and responsibility.
+
+Persistence backends may include JDBC, in-memory, NoSQL, test fixtures, or other
+implementations. A finding may be backend-specific when it depends on
+transaction semantics, consistency, uniqueness constraints, secret storage,
+query behavior, serialization, indexing, cleanup behavior, or backend-specific
+configuration.
+
+Authentication modes may include internal Polaris principals and secrets,
+external OIDC identity providers, or mixed configurations. A finding may be
+authentication-mode-specific when it depends on token validation, claim mapping,
+realm selection, tenant mapping, credential reset, client secrets, token
+exchange, or principal provisioning.
+
+Authorization may be enforced through internal Polaris RBAC, external policy
+decision points, Ranger, OPA, or mixed decision paths. A finding may be
+authorization-mode-specific when it depends on privilege derivation, request
+context passed to an external service, policy fallback behavior, deny/allow
+precedence, fail-open or fail-closed behavior, caching, or mismatches between
+internal and external decisions.
+
+When evaluating a finding, identify:
+
+- The persistence backend involved.
+- The authentication mode involved.
+- The authorization service or model involved.
+- Whether the behavior is common across variants or variant-specific.
+- Whether unsupported, test-only, or development-only variants are required.
+- Whether a production-supported configuration is affected.
+
+A finding may be valid when it affects:
+
+- All variants.
+- One specific supported variant.
+- A documented combination of variants.
+- An optional implementation present in an official artifact but activated only
+  by configuration.
+
+A finding is weaker, and may be a false positive, when it requires combining
+mutually exclusive runtime assumptions or test-only behavior that is not
+reachable in a supported deployment.
+
+Security invariants must hold consistently across supported variants unless a
+variant-specific limitation is explicitly documented.
+
+External authorization integrations must receive enough request context to make
+the intended decision and must fail according to documented fail-open or
+fail-closed behavior.
+
+Internal and external authorization paths must not disagree in a way that grants
+access broader than the configured policy intends.
+
+Persistence backends must preserve authorization-relevant invariants such as
+principal identity, role grants, privilege scope, catalog boundaries, credential
+state, and entity uniqueness.
+
+## Related Polaris Tools
+
+Related tools maintained by the Apache Polaris project may affect Polaris
+security when they are released, documented for user or operator use, handle
+Polaris credentials or metadata, expose reachable interfaces, or can affect a
+Polaris deployment through administration, migration, synchronization,
+credential handling, generated artifacts, or copied examples.
+
+These tools can have different audiences, deployment models, protected assets,
+and trust boundaries than the Polaris server. Evaluate findings against the
+tool-specific threat model and agent guidance in the tools repository where
+available. A finding in a related tool is not automatically a Polaris server
+vulnerability.
+
+## Upstream Dependencies
+
+Polaris depends on Apache Iceberg and other open source projects. Vulnerabilities
+in those dependencies can affect Polaris when Polaris exposes the vulnerable
+behavior through a reachable code path, depends on the vulnerable behavior for a
+security decision, ships an affected dependency in a supported distribution, or
+uses unsafe configuration that changes the impact.
+
+A dependency vulnerability is not automatically a Polaris vulnerability. When
+evaluating one, determine whether:
+
+- The vulnerable dependency code is present in a supported Polaris artifact.
+- The vulnerable behavior is reachable through Polaris.
+- Exploitation crosses a Polaris trust boundary.
+- Polaris authentication, authorization, metadata, credentials, or configuration
+  are affected.
+- Polaris needs a release, mitigation, configuration change, or advisory.
+
+Respect the upstream project's security policy and disclosure process. Do not
+include non-public upstream vulnerability details in Polaris issues, commits,
+documentation, tests, or public discussions unless the information has already
+been publicly disclosed or coordinated disclosure explicitly permits it.
+
+## Security-Relevant Documentation Findings
+
+Documentation, examples, defaults, and generated reference material can affect
+security when they shape how users deploy, configure, integrate, or operate
+Polaris.
+
+A documentation issue may be security-relevant when it could reasonably cause
+users, operators, integrators, or downstream tool authors to misunderstand a
+security boundary, protected asset, trust assumption, default behavior, supported
+configuration, operational responsibility, or security-sensitive workflow.
+
+Examples include, but are not limited to, documentation that could lead users to:
+
+- Store secrets in client-visible properties or metadata.
+- Expose protected APIs, tools, or admin interfaces unintentionally.
+- Assume credentials, tokens, storage policies, or access boundaries are
+  narrower than they are.
+- Use development-only defaults or examples in production.
+- Misunderstand authentication, authorization, role scope, realm scope, or
+  external policy behavior.
+- Configure storage, federation, identity providers, policy services, TLS, or
+  endpoints in a way that weakens intended security.
+- Miss provider-specific limitations that affect isolation or credential scope.
+
+This category applies across all Polaris areas, including server behavior,
+clients, tools, packaging, deployment, configuration, authentication,
+authorization, storage, federation, persistence backends, policy integrations,
+dependency usage, upgrade guidance, and examples.
+
+Security-relevant documentation findings are not automatically Polaris
+vulnerabilities and do not automatically require an advisory or CVE. They should
+still be reported as hardening or operator-safety findings when clearer
+documentation could prevent realistic misuse.
+
+ASF security guidance remains authoritative for whether a finding should be
+handled as an undisclosed vulnerability, advisory, CVE, normal bug, or
+documentation hardening item.
+
+When reporting such a finding, identify:
+
+- The documented behavior, example, or missing warning.
+- The security assumption a user may incorrectly make.
+- The actor, asset, or boundary affected by the misunderstanding.
+- Whether the underlying product behavior is correct, unsafe, or ambiguous.
+- Proposed safer wording or placement for the clarification.
+
+## Guidance For Automated Analysis
+
+When evaluating a potential finding:
+
+1. Identify the actor required to exploit it.
+2. Identify the protected asset affected.
+3. Identify the trust boundary crossed.
+4. Identify the missing or incorrect security invariant.
+5. Distinguish between:
+   - a vulnerability in Polaris,
+   - a deployment misconfiguration,
+   - a dependency vulnerability not exposed by Polaris,
+   - a false positive caused by test, demo, or unreachable code.
+6. Prefer findings with a concrete reachable path from an untrusted or
+   lower-privileged actor to unauthorized access, mutation, disclosure, or
+   privilege escalation.
+7. For findings involving packaging, optional dependencies, Gradle properties,
+   container images, Helm charts, or custom distributions, identify the exact
+   source revision, such as the official source release version, Git commit,
+   branch, or tag, along with the selected modules, enabled Gradle properties,
+   optional extensions, packaging format, and deployment-relevant configuration
+   before assessing reachability, supported status, and severity.
+8. For findings involving related Polaris tools, use the tool-specific threat
+   model and agent guidance where available. A finding in a related tool is not
+   automatically a Polaris server vulnerability.
+9. For findings involving storage locations or credential vending, enumerate all
+   URI-bearing inputs and metadata fields used by the operation, identify when
+   they are validated, and verify that the same effective locations are used for
+   authorization, persistence, storage access, and delegated credential scope.
+10. For findings involving properties or configuration values, classify whether
+    each value is secret, operator-visible, management-plane visible,
+    data-plane client-visible, logged, stored in local profiles, or exported to
+    generated artifacts.
+11. For findings involving tokens, principal credentials, reset, rotation, or
+    token exchange, identify the principal, realm, requested scope, effective
+    scope, expiration, revocation behavior, and whether previously issued
+    credentials or tokens can still cross the intended boundary.
+12. For findings involving existence checks, compare `not found` and
+    `forbidden` behavior and decide whether the target object's existence,
+    name, or relationship is itself a protected asset in the relevant
+    deployment.
+13. For findings involving external endpoints, federation, object stores, or
+    policy integrations, identify which party controls the endpoint, which
+    credentials or metadata are sent to it, whether transport security is
+    required, and whether redirects or custom endpoints can cross a trust
+    boundary.
+14. For variant-specific findings, do not mix assumptions from different
+    persistence backends, authentication modes, authorization services, storage
+    providers, optional extensions, or deployment profiles unless the
+    combination is supported and reachable in one coherent deployment. Identify
+    the concrete configuration under which the finding is reachable, or state
+    that the finding is common across variants.
+15. For documentation findings, separate security-relevant documentation issues

Review Comment:
   Good catch.
   Ambiguity in such rule/instruction docs is never good, no matter whether it's a human or an AI.
   



##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal
+  authorized for one logical entity to access another logical entity's data or
+  metadata.
+- Provider policy documents and expressions must escape or otherwise safely
+  encode caller-controlled identifiers, paths, and property values.
+- User-controlled input must not be used to construct SQL, filesystem paths,
+  object-store paths, URLs, or process commands without appropriate validation or
+  safe APIs.
+- Error messages must not disclose secrets or unauthorized metadata.
+- Existence, names, and relationships of principals, roles, catalogs,
+  namespaces, tables, views, and policies must not be disclosed to unauthorized
+  callers unless that disclosure is explicitly documented and accepted.
+- Configuration changes that create, reset, rotate, store, or delete credentials
+  or secrets must be authorized, consistently applied, and must not leave stale
+  credentials or orphaned secrets with unintended access.
+- Internal and administrative APIs must not be exposed as public unauthenticated
+  APIs.
+- Optional build features, extensions, and distribution-specific packaging must
+  not weaken Polaris authentication, authorization, credential handling, or
+  metadata isolation without explicit configuration and documentation.
+
+## Security Issues
+
+The following should generally be treated as potential security vulnerabilities:
+
+- Authentication bypass.
+- Authorization bypass or privilege escalation.
+- Cross-catalog or cross-realm data access caused by missing checks.
+- Unauthorized mutation of catalog metadata, roles, policies, or principals.
+- Exposure of credentials, tokens, secrets, or sensitive configuration.
+- Exposure of secrets through client-visible properties, configuration
+  responses, logs, profiles, command output, browser storage, or generated
+  artifacts.
+- Credential-vending behavior that grants broader storage access than the
+  caller's authorized operation or effective storage boundary.
+- Storage-location validation bypasses, including unvalidated URI-bearing table
+  metadata, reused or overlapping locations, and provider-policy construction
+  issues.
+- Token or credential lifecycle issues that allow access to continue beyond the
+  intended reset, rotation, revocation, realm, or scope boundary.
+- Unauthorized disclosure of identity, role, policy, catalog, namespace, table,
+  or view existence when that existence is itself sensitive.
+- SQL injection, command injection, unsafe deserialization, server-side request
+  forgery, path traversal, or template injection reachable through untrusted
+  input.
+- Unsafe use of externally configured endpoints that can redirect privileged
+  traffic, credentials, tokens, metadata, or storage requests outside the
+  intended trust relationship.
+- Logging or returning sensitive values to unauthorized users.
+- Use of weak cryptographic validation for authentication or authorization
+  decisions.
+- Insecure defaults that expose protected APIs or disable required security
+  checks.
+
+## Non-Issues And Deployment Responsibilities
+
+The following are not normally treated as Polaris vulnerabilities by themselves:
+
+- A deployment operator choosing weak credentials or exposing the service
+  publicly without required network controls.
+- A compromised administrator using their legitimate administrative privileges.
+- A compromised database, object store, Kubernetes cluster, host operating
+  system, identity provider, or external policy decision point.
+- Lack of rate limiting unless it enables a concrete security impact beyond
+  resource exhaustion.
+- Information visible to a principal that is explicitly authorized to access it.
+- Storage-provider limitations that are accurately documented and do not give
+  Polaris callers more access than the deployment intentionally configured.
+- Test-only code, local development defaults, or example configuration not used
+  in production paths, unless clearly reachable in production builds.
+
+Polaris does not, by itself, provide the following security properties:
+
+- Protection after compromise of deployment infrastructure, persistence
+  backends, object stores, identity providers, external policy decision points,
+  Kubernetes clusters, hosts, or administrator workstations.
+- Protection against authorized administrators using their legitimate privileges
+  in ways the deployment does not intend.
+- Network isolation, TLS termination, firewalling, ingress policy, Kubernetes
+  policy, or cloud-account isolation beyond what the deployment provides.
+- Secret management for values that operators place outside Polaris-controlled
+  secret storage or configuration mechanisms.
+- Stronger delegated-credential isolation than the selected storage provider,
+  configured policy model, and documented deployment mode can support.
+- Safety of arbitrary downstream packaging, module combinations, integrations,
+  or local patches that are not part of an official Polaris artifact or
+  documented supported configuration.
+
+Deployment operators and downstream integrators are responsible for:
+
+- Protecting service credentials, signing keys, client secrets, object-store
+  credentials, identity-provider configuration, policy-service credentials, and
+  local CLI or admin-tool profiles.
+- Configuring TLS, network exposure, ingress, firewalls, service accounts,
+  Kubernetes permissions, cloud IAM, object-store policy, and persistence-backend
+  access according to the deployment's security requirements.
+- Choosing production-appropriate authentication, authorization, persistence,
+  storage, and policy-service settings before exposing Polaris to untrusted
+  clients.
+- Avoiding production use of local-development defaults, sample credentials,
+  test fixtures, example configuration, and benchmark-only tooling unless those
+  choices are explicitly intended and protected.
+- Rotating and revoking credentials, tokens, secrets, and delegated access
+  according to the deployment's operational requirements.
+- Protecting logs, generated configuration, local profiles, backups, database
+  snapshots, object-store metadata, and other artifacts that may contain
+  security-sensitive values.
+
+The following patterns often require careful triage because they can be
+vulnerabilities, documentation hardening items, deployment responsibilities, or
+false positives depending on the actor, configuration, and reachable path:
+
+- Treating client-visible properties, catalog metadata, generated configuration,
+  local profiles, command output, browser storage, or logs as secret stores.
+- Assuming delegated storage credentials are narrower than the configured
+  provider policy, access-boundary mechanism, or documented deployment mode
+  actually supports.
+- Assuming every custom build, Gradle project combination, optional dependency,
+  extension, or downstream package is an official supported Polaris artifact.
+- Applying server threat-model assumptions unchanged to CLIs, web UIs,
+  migration tools, MCP servers, synchronization tools, benchmarks, or other
+  related tools.
+- Treating test fixtures, mocked trust decisions, direct internal object
+  construction, or already-authorized access as proof of a production
+  vulnerability.
+- Treating dependency advisories as Polaris vulnerabilities without showing that
+  the vulnerable behavior is present, reachable, and crosses a Polaris trust
+  boundary.
+
+Known non-findings are cases already covered by the non-issues, dependency,
+variant, distribution, and related-tool sections above. Common examples include
+authorized access, unreachable dependency advisories, test-only behavior,
+compromised deployment infrastructure, and impossible variant combinations.
+
+## Consumption And Distribution Boundaries
+
+Users consume Polaris in several ways, including:
+
+- Release tarballs containing the runnable Quarkus applications for the Polaris
+  server and Polaris admin tool.
+- Container images for the Polaris server and Polaris admin tool.
+- Helm charts for deploying the Polaris server.
+- The Python-based CLI tool under `client/`.
+- Custom applications or distributions built from Polaris modules such as
+  `polaris-core`, `polaris-runtime-service`, extension modules, or other Gradle
+  project combinations.
+
+The Polaris threat model applies directly to artifacts and modules produced by
+the Apache Polaris project. It also applies to custom distributions when they use
+Polaris code to make authentication, authorization, catalog metadata, policy, or
+credential-handling decisions.
+
+Custom distributions can change the effective threat model. When evaluating a
+finding, determine whether the behavior is present in:
+
+- An official Polaris release artifact.

Review Comment:
   Right, "documented build from source" should be covered, most likely. A clarification doesn't hurt though.



##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal
+  authorized for one logical entity to access another logical entity's data or
+  metadata.
+- Provider policy documents and expressions must escape or otherwise safely
+  encode caller-controlled identifiers, paths, and property values.
+- User-controlled input must not be used to construct SQL, filesystem paths,
+  object-store paths, URLs, or process commands without appropriate validation or
+  safe APIs.
+- Error messages must not disclose secrets or unauthorized metadata.
+- Existence, names, and relationships of principals, roles, catalogs,
+  namespaces, tables, views, and policies must not be disclosed to unauthorized
+  callers unless that disclosure is explicitly documented and accepted.
+- Configuration changes that create, reset, rotate, store, or delete credentials
+  or secrets must be authorized, consistently applied, and must not leave stale
+  credentials or orphaned secrets with unintended access.
+- Internal and administrative APIs must not be exposed as public unauthenticated
+  APIs.
+- Optional build features, extensions, and distribution-specific packaging must
+  not weaken Polaris authentication, authorization, credential handling, or
+  metadata isolation without explicit configuration and documentation.
+
+## Security Issues
+
+The following should generally be treated as potential security vulnerabilities:
+
+- Authentication bypass.
+- Authorization bypass or privilege escalation.
+- Cross-catalog or cross-realm data access caused by missing checks.
+- Unauthorized mutation of catalog metadata, roles, policies, or principals.
+- Exposure of credentials, tokens, secrets, or sensitive configuration.
+- Exposure of secrets through client-visible properties, configuration
+  responses, logs, profiles, command output, browser storage, or generated
+  artifacts.
+- Credential-vending behavior that grants broader storage access than the
+  caller's authorized operation or effective storage boundary.
+- Storage-location validation bypasses, including unvalidated URI-bearing table
+  metadata, reused or overlapping locations, and provider-policy construction
+  issues.
+- Token or credential lifecycle issues that allow access to continue beyond the
+  intended reset, rotation, revocation, realm, or scope boundary.
+- Unauthorized disclosure of identity, role, policy, catalog, namespace, table,
+  or view existence when that existence is itself sensitive.
+- SQL injection, command injection, unsafe deserialization, server-side request
+  forgery, path traversal, or template injection reachable through untrusted
+  input.
+- Unsafe use of externally configured endpoints that can redirect privileged
+  traffic, credentials, tokens, metadata, or storage requests outside the
+  intended trust relationship.
+- Logging or returning sensitive values to unauthorized users.
+- Use of weak cryptographic validation for authentication or authorization
+  decisions.
+- Insecure defaults that expose protected APIs or disable required security
+  checks.
+
+## Non-Issues And Deployment Responsibilities
+
+The following are not normally treated as Polaris vulnerabilities by themselves:
+
+- A deployment operator choosing weak credentials or exposing the service
+  publicly without required network controls.
+- A compromised administrator using their legitimate administrative privileges.
+- A compromised database, object store, Kubernetes cluster, host operating
+  system, identity provider, or external policy decision point.
+- Lack of rate limiting unless it enables a concrete security impact beyond
+  resource exhaustion.
+- Information visible to a principal that is explicitly authorized to access it.
+- Storage-provider limitations that are accurately documented and do not give
+  Polaris callers more access than the deployment intentionally configured.
+- Test-only code, local development defaults, or example configuration not used
+  in production paths, unless clearly reachable in production builds.
+
+Polaris does not, by itself, provide the following security properties:
+
+- Protection after compromise of deployment infrastructure, persistence
+  backends, object stores, identity providers, external policy decision points,
+  Kubernetes clusters, hosts, or administrator workstations.
+- Protection against authorized administrators using their legitimate privileges
+  in ways the deployment does not intend.
+- Network isolation, TLS termination, firewalling, ingress policy, Kubernetes
+  policy, or cloud-account isolation beyond what the deployment provides.
+- Secret management for values that operators place outside Polaris-controlled
+  secret storage or configuration mechanisms.
+- Stronger delegated-credential isolation than the selected storage provider,
+  configured policy model, and documented deployment mode can support.
+- Safety of arbitrary downstream packaging, module combinations, integrations,
+  or local patches that are not part of an official Polaris artifact or
+  documented supported configuration.
+
+Deployment operators and downstream integrators are responsible for:
+
+- Protecting service credentials, signing keys, client secrets, object-store
+  credentials, identity-provider configuration, policy-service credentials, and
+  local CLI or admin-tool profiles.
+- Configuring TLS, network exposure, ingress, firewalls, service accounts,
+  Kubernetes permissions, cloud IAM, object-store policy, and persistence-backend
+  access according to the deployment's security requirements.
+- Choosing production-appropriate authentication, authorization, persistence,
+  storage, and policy-service settings before exposing Polaris to untrusted
+  clients.
+- Avoiding production use of local-development defaults, sample credentials,
+  test fixtures, example configuration, and benchmark-only tooling unless those
+  choices are explicitly intended and protected.
+- Rotating and revoking credentials, tokens, secrets, and delegated access
+  according to the deployment's operational requirements.
+- Protecting logs, generated configuration, local profiles, backups, database
+  snapshots, object-store metadata, and other artifacts that may contain
+  security-sensitive values.
+
+The following patterns often require careful triage because they can be
+vulnerabilities, documentation hardening items, deployment responsibilities, or
+false positives depending on the actor, configuration, and reachable path:
+
+- Treating client-visible properties, catalog metadata, generated configuration,
+  local profiles, command output, browser storage, or logs as secret stores.
+- Assuming delegated storage credentials are narrower than the configured
+  provider policy, access-boundary mechanism, or documented deployment mode
+  actually supports.
+- Assuming every custom build, Gradle project combination, optional dependency,
+  extension, or downstream package is an official supported Polaris artifact.
+- Applying server threat-model assumptions unchanged to CLIs, web UIs,
+  migration tools, MCP servers, synchronization tools, benchmarks, or other
+  related tools.
+- Treating test fixtures, mocked trust decisions, direct internal object
+  construction, or already-authorized access as proof of a production
+  vulnerability.
+- Treating dependency advisories as Polaris vulnerabilities without showing that
+  the vulnerable behavior is present, reachable, and crosses a Polaris trust
+  boundary.
+
+Known non-findings are cases already covered by the non-issues, dependency,
+variant, distribution, and related-tool sections above. Common examples include
+authorized access, unreachable dependency advisories, test-only behavior,
+compromised deployment infrastructure, and impossible variant combinations.
+
+## Consumption And Distribution Boundaries
+
+Users consume Polaris in several ways, including:
+
+- Release tarballs containing the runnable Quarkus applications for the Polaris
+  server and Polaris admin tool.
+- Container images for the Polaris server and Polaris admin tool.
+- Helm charts for deploying the Polaris server.
+- The Python-based CLI tool under `client/`.
+- Custom applications or distributions built from Polaris modules such as
+  `polaris-core`, `polaris-runtime-service`, extension modules, or other Gradle
+  project combinations.
+
+The Polaris threat model applies directly to artifacts and modules produced by
+the Apache Polaris project. It also applies to custom distributions when they use
+Polaris code to make authentication, authorization, catalog metadata, policy, or
+credential-handling decisions.
+
+Custom distributions can change the effective threat model. When evaluating a
+finding, determine whether the behavior is present in:
+
+- An official Polaris release artifact.
+- An official Polaris container image.
+- An official Polaris Helm chart.
+- The Polaris CLI.
+- A reusable Polaris module.

Review Comment:
   Right, production code - but not tests, fixtures, docs etc.



##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal
+  authorized for one logical entity to access another logical entity's data or
+  metadata.
+- Provider policy documents and expressions must escape or otherwise safely
+  encode caller-controlled identifiers, paths, and property values.
+- User-controlled input must not be used to construct SQL, filesystem paths,
+  object-store paths, URLs, or process commands without appropriate validation or
+  safe APIs.
+- Error messages must not disclose secrets or unauthorized metadata.
+- Existence, names, and relationships of principals, roles, catalogs,
+  namespaces, tables, views, and policies must not be disclosed to unauthorized
+  callers unless that disclosure is explicitly documented and accepted.
+- Configuration changes that create, reset, rotate, store, or delete credentials
+  or secrets must be authorized, consistently applied, and must not leave stale
+  credentials or orphaned secrets with unintended access.
+- Internal and administrative APIs must not be exposed as public unauthenticated
+  APIs.
+- Optional build features, extensions, and distribution-specific packaging must
+  not weaken Polaris authentication, authorization, credential handling, or
+  metadata isolation without explicit configuration and documentation.
+
+## Security Issues
+
+The following should generally be treated as potential security vulnerabilities:
+
+- Authentication bypass.
+- Authorization bypass or privilege escalation.
+- Cross-catalog or cross-realm data access caused by missing checks.
+- Unauthorized mutation of catalog metadata, roles, policies, or principals.
+- Exposure of credentials, tokens, secrets, or sensitive configuration.
+- Exposure of secrets through client-visible properties, configuration
+  responses, logs, profiles, command output, browser storage, or generated
+  artifacts.
+- Credential-vending behavior that grants broader storage access than the
+  caller's authorized operation or effective storage boundary.
+- Storage-location validation bypasses, including unvalidated URI-bearing table
+  metadata, reused or overlapping locations, and provider-policy construction
+  issues.
+- Token or credential lifecycle issues that allow access to continue beyond the
+  intended reset, rotation, revocation, realm, or scope boundary.
+- Unauthorized disclosure of identity, role, policy, catalog, namespace, table,
+  or view existence when that existence is itself sensitive.
+- SQL injection, command injection, unsafe deserialization, server-side request
+  forgery, path traversal, or template injection reachable through untrusted
+  input.
+- Unsafe use of externally configured endpoints that can redirect privileged
+  traffic, credentials, tokens, metadata, or storage requests outside the
+  intended trust relationship.
+- Logging or returning sensitive values to unauthorized users.
+- Use of weak cryptographic validation for authentication or authorization
+  decisions.
+- Insecure defaults that expose protected APIs or disable required security
+  checks.
+
+## Non-Issues And Deployment Responsibilities
+
+The following are not normally treated as Polaris vulnerabilities by themselves:
+
+- A deployment operator choosing weak credentials or exposing the service
+  publicly without required network controls.
+- A compromised administrator using their legitimate administrative privileges.
+- A compromised database, object store, Kubernetes cluster, host operating
+  system, identity provider, or external policy decision point.
+- Lack of rate limiting unless it enables a concrete security impact beyond
+  resource exhaustion.
+- Information visible to a principal that is explicitly authorized to access it.
+- Storage-provider limitations that are accurately documented and do not give
+  Polaris callers more access than the deployment intentionally configured.
+- Test-only code, local development defaults, or example configuration not used
+  in production paths, unless clearly reachable in production builds.
+
+Polaris does not, by itself, provide the following security properties:
+
+- Protection after compromise of deployment infrastructure, persistence
+  backends, object stores, identity providers, external policy decision points,
+  Kubernetes clusters, hosts, or administrator workstations.
+- Protection against authorized administrators using their legitimate privileges
+  in ways the deployment does not intend.
+- Network isolation, TLS termination, firewalling, ingress policy, Kubernetes
+  policy, or cloud-account isolation beyond what the deployment provides.
+- Secret management for values that operators place outside Polaris-controlled
+  secret storage or configuration mechanisms.
+- Stronger delegated-credential isolation than the selected storage provider,
+  configured policy model, and documented deployment mode can support.
+- Safety of arbitrary downstream packaging, module combinations, integrations,
+  or local patches that are not part of an official Polaris artifact or
+  documented supported configuration.
+
+Deployment operators and downstream integrators are responsible for:
+
+- Protecting service credentials, signing keys, client secrets, object-store
+  credentials, identity-provider configuration, policy-service credentials, and
+  local CLI or admin-tool profiles.
+- Configuring TLS, network exposure, ingress, firewalls, service accounts,
+  Kubernetes permissions, cloud IAM, object-store policy, and persistence-backend
+  access according to the deployment's security requirements.
+- Choosing production-appropriate authentication, authorization, persistence,
+  storage, and policy-service settings before exposing Polaris to untrusted
+  clients.
+- Avoiding production use of local-development defaults, sample credentials,
+  test fixtures, example configuration, and benchmark-only tooling unless those
+  choices are explicitly intended and protected.
+- Rotating and revoking credentials, tokens, secrets, and delegated access
+  according to the deployment's operational requirements.
+- Protecting logs, generated configuration, local profiles, backups, database
+  snapshots, object-store metadata, and other artifacts that may contain
+  security-sensitive values.
+
+The following patterns often require careful triage because they can be
+vulnerabilities, documentation hardening items, deployment responsibilities, or
+false positives depending on the actor, configuration, and reachable path:
+
+- Treating client-visible properties, catalog metadata, generated configuration,
+  local profiles, command output, browser storage, or logs as secret stores.
+- Assuming delegated storage credentials are narrower than the configured
+  provider policy, access-boundary mechanism, or documented deployment mode
+  actually supports.
+- Assuming every custom build, Gradle project combination, optional dependency,
+  extension, or downstream package is an official supported Polaris artifact.
+- Applying server threat-model assumptions unchanged to CLIs, web UIs,
+  migration tools, MCP servers, synchronization tools, benchmarks, or other
+  related tools.
+- Treating test fixtures, mocked trust decisions, direct internal object
+  construction, or already-authorized access as proof of a production
+  vulnerability.
+- Treating dependency advisories as Polaris vulnerabilities without showing that
+  the vulnerable behavior is present, reachable, and crosses a Polaris trust
+  boundary.
+
+Known non-findings are cases already covered by the non-issues, dependency,
+variant, distribution, and related-tool sections above. Common examples include
+authorized access, unreachable dependency advisories, test-only behavior,
+compromised deployment infrastructure, and impossible variant combinations.
+
+## Consumption And Distribution Boundaries
+
+Users consume Polaris in several ways, including:
+
+- Release tarballs containing the runnable Quarkus applications for the Polaris
+  server and Polaris admin tool.
+- Container images for the Polaris server and Polaris admin tool.
+- Helm charts for deploying the Polaris server.
+- The Python-based CLI tool under `client/`.
+- Custom applications or distributions built from Polaris modules such as
+  `polaris-core`, `polaris-runtime-service`, extension modules, or other Gradle
+  project combinations.
+
+The Polaris threat model applies directly to artifacts and modules produced by
+the Apache Polaris project. It also applies to custom distributions when they use
+Polaris code to make authentication, authorization, catalog metadata, policy, or
+credential-handling decisions.
+
+Custom distributions can change the effective threat model. When evaluating a
+finding, determine whether the behavior is present in:
+
+- An official Polaris release artifact.
+- An official Polaris container image.
+- An official Polaris Helm chart.
+- The Polaris CLI.
+- A reusable Polaris module.
+- An optional extension or dependency enabled by build configuration.
+- Downstream-only integration code or deployment packaging.
+

Review Comment:
   Yup, more details are below.
   How for example a generated report looks like depends on a lot of things.
   It's probably a learning experience 🤷 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["dennishuo (via GitHub)" <gi...@apache.org>]

dennishuo commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3249857897


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,734 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata whose visibility is governed by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already

Review Comment:
   The "already have authority to grant" part of this one seems difficult to define in this context since on a technical level the success of the self-grant is proof of the *observed* authority to grant something.
   
   If we're talking about divergence from the spec, we might want to qualify this statement with how we define the spec's "intended" authority.
   
   Alternatively, the trickier one that's probably more often to be the security issue is to flag when a *second-order* effect allows escaping the privilege boundary, e.g. if there's a set of privilege self-grant requests that are all normally rejected when directly attempted by the principal/role, but by creating a new role and granting those rejected privileges to the new role and then self-granting the new role allows escaping, then that's a breaking of invariant to flag.



##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,734 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata whose visibility is governed by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not

Review Comment:
   Can you clarify this sentence a bit? In this case does "callers" mean internal callsites, or external user calls? I'm assuming internal callsites.
   
   So are we just saying that some persistence calls might happen before authorization is performed (so retrieval from persistence isn't proof of ability to return something to the external caller, e.g. if we want to allow cache-prefetching and accept the risk of DDoS by post-authn but pre-authz calls?)



##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal

Review Comment:
   I think we could still qualify this one a bit more, since the logic of this one seems a bit off. Is this saying that such "reused, overlapping, or ambiguous storage locations" themselves must not exist, or is it saying that "Given(Exists(overlapping storage locations)) => !Exists(overlapping storage access)"?
   
   If it's saying they shouldn't exist, then it should be qualified "unless explicitly configured to do so" since there's DISABLE_OVERLAP_CHECKs, and there's table clones, etc.
   
   If it's saying given the overlapping locations already, we still can't allow cross-table access with one credential, then it's fundamentally impossible in the current credential-vending implementation, which is a *known* limitation, not a new vulnerability to detect. That would mean either we already need to disable the core feature in favor of finer-grained table storage controls, or always need to break "invariants".
   
   In all cases we also need to qualify whether we intend for this to mean "within a realm" or "within a Polaris deployment" or "across all Polaris deployments".



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["RussellSpitzer (via GitHub)" <gi...@apache.org>]

RussellSpitzer commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3244095168


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |

Review Comment:
   nit, it's under client/python/ shouldn't slow down an agent too much but probably worth fixing



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["flyingImer (via GitHub)" <gi...@apache.org>]

flyingImer commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3270066589


##########
AGENTS.md:
##########
@@ -277,3 +277,71 @@ Do not include AI tool names or model identifiers in code, comments, or commit
 messages. For PR descriptions, follow the disclosure guidance in
 [CONTRIBUTING.md](CONTRIBUTING.md#guidelines-for-ai-assisted-contributions).
 The human author owns the contribution.
+
+## Security issues
+
+Before reporting or fixing security issues, read
+[`SECURITY-THREAT-MODEL.md`](SECURITY-THREAT-MODEL.md). Use it to determine
+whether a finding crosses a Polaris security boundary, which actor can exploit it,
+what protected asset is affected, and whether the issue is a Polaris
+vulnerability, a deployment responsibility, a dependency issue, or a false
+positive.
+
+Use [`SECURITY.md`](SECURITY.md) and the public
+[security reporting page](https://polaris.apache.org/community/security-report/)
+for reporting process, disclosure handling, and where suspected vulnerabilities
+should be sent. The public security reporting page also lists previously
+published advisories and CVEs; treat those as public historical examples of issue
+classes, not as substitutes for the threat model's boundaries and invariants.
+
+For dependency-related findings, check whether the vulnerable behavior is
+reachable through Polaris, whether it affects a Polaris security boundary or
+protected asset, and whether the upstream project's security policy or disclosure
+process applies.
+
+For packaging, optional-feature, or custom-build findings, identify the exact
+source revision, selected modules, enabled Gradle properties, optional
+extensions, packaging format, and deployment-relevant configuration before
+assessing reachability, supported status, severity, or whether the issue belongs
+to Polaris or downstream integration code.
+
+For findings in related Polaris tools, including tools from `apache/polaris-tools`,
+use the tool-specific threat model and agent guidance in that repository where
+available. A finding in a related tool is not automatically a Polaris server
+vulnerability.
+
+For findings involving storage locations, credential vending, properties,
+configuration, tokens, credential reset, token exchange, externally configured
+endpoints, or existence checks, classify the protected asset and trust boundary
+using `SECURITY-THREAT-MODEL.md` before deciding whether the behavior is a
+Polaris vulnerability, deployment responsibility, upstream issue, or false
+positive.
+
+For findings involving persistence, authentication, authorization, storage, or
+extension variants, identify the concrete backend, authentication mode,
+authorization model, policy service, storage provider, and deployment profile
+before deciding reachability or severity. Do not assume behavior in JDBC,
+in-memory, NoSQL, internal RBAC, OIDC, OPA, Ranger, or mixed deployments is
+identical, and do not combine assumptions from mutually exclusive variants.
+
+Report security-relevant documentation issues separately from vulnerabilities
+when unclear docs, examples, defaults, or missing warnings could reasonably lead
+users to unsafe deployment, credential handling, authorization, storage,
+integration, upgrade, or operational choices.
+
+Use ASF security guidance for process and classification; do not infer advisory
+or CVE status from `SECURITY-THREAT-MODEL.md` alone.
+
+When reporting potential findings, label ASF severity, proof status, and
+CVE/advisory status as non-authoritative triage estimates.
+
+Do not treat a test as proof of a vulnerability unless it demonstrates that the
+stated actor can cross a real trust boundary without already-authorized access,
+privileged fixtures, mocked trust decisions, or protected information.
+
+Avoid over-reporting findings that are only security-adjacent and lack a
+realistic path to impact or realistic user misunderstanding.
+
+Do not include private vulnerability details, exploit payloads, reporter names,
+private mailing-list content, secrets, or non-public infrastructure details in
+code, comments, tests, documentation, commit messages, or PR descriptions.

Review Comment:
   ~70 lines here largely restate SECURITY-THREAT-MODEL.md. 2 cents: compress to a pointer plus the two non-negotiables.
   
   ```md
   ## Security Issues
   
   Before reporting or fixing security issues, read [`SECURITY-THREAT-MODEL.md`](SECURITY-THREAT-MODEL.md) to determine whether a finding is a Polaris vulnerability, a deployment responsibility, a dependency issue, or a false positive. Use [`SECURITY.md`](SECURITY.md) and the [security reporting page](https://polaris.apache.org/community/security-report/) for reporting process and disclosure handling.
   
   ASF severity, advisory status, and CVE candidacy are non-authoritative triage estimates. Do not infer them from `SECURITY-THREAT-MODEL.md` alone.
   
   Do not include private vulnerability details, exploit payloads, reporter names, private mailing-list content, secrets, or non-public infrastructure details in code, comments, tests, documentation, commit messages, or PR descriptions.
   ```
   
   The category guidance (storage, persistence, packaging, optional integrations, related tools, variants, dependencies, documentation findings) is already in SECURITY-THREAT-MODEL.md. Inline restatement just doubles maintenance.



##########
AGENTS.md:
##########
@@ -277,3 +277,71 @@ Do not include AI tool names or model identifiers in code, comments, or commit
 messages. For PR descriptions, follow the disclosure guidance in
 [CONTRIBUTING.md](CONTRIBUTING.md#guidelines-for-ai-assisted-contributions).
 The human author owns the contribution.
+
+## Security issues
+
+Before reporting or fixing security issues, read
+[`SECURITY-THREAT-MODEL.md`](SECURITY-THREAT-MODEL.md). Use it to determine
+whether a finding crosses a Polaris security boundary, which actor can exploit it,
+what protected asset is affected, and whether the issue is a Polaris
+vulnerability, a deployment responsibility, a dependency issue, or a false
+positive.
+
+Use [`SECURITY.md`](SECURITY.md) and the public
+[security reporting page](https://polaris.apache.org/community/security-report/)
+for reporting process, disclosure handling, and where suspected vulnerabilities
+should be sent. The public security reporting page also lists previously
+published advisories and CVEs; treat those as public historical examples of issue
+classes, not as substitutes for the threat model's boundaries and invariants.
+
+For dependency-related findings, check whether the vulnerable behavior is
+reachable through Polaris, whether it affects a Polaris security boundary or
+protected asset, and whether the upstream project's security policy or disclosure
+process applies.
+
+For packaging, optional-feature, or custom-build findings, identify the exact
+source revision, selected modules, enabled Gradle properties, optional
+extensions, packaging format, and deployment-relevant configuration before
+assessing reachability, supported status, severity, or whether the issue belongs
+to Polaris or downstream integration code.
+
+For findings in related Polaris tools, including tools from `apache/polaris-tools`,
+use the tool-specific threat model and agent guidance in that repository where
+available. A finding in a related tool is not automatically a Polaris server
+vulnerability.
+
+For findings involving storage locations, credential vending, properties,
+configuration, tokens, credential reset, token exchange, externally configured
+endpoints, or existence checks, classify the protected asset and trust boundary
+using `SECURITY-THREAT-MODEL.md` before deciding whether the behavior is a
+Polaris vulnerability, deployment responsibility, upstream issue, or false
+positive.
+
+For findings involving persistence, authentication, authorization, storage, or
+extension variants, identify the concrete backend, authentication mode,
+authorization model, policy service, storage provider, and deployment profile
+before deciding reachability or severity. Do not assume behavior in JDBC,
+in-memory, NoSQL, internal RBAC, OIDC, OPA, Ranger, or mixed deployments is
+identical, and do not combine assumptions from mutually exclusive variants.

Review Comment:
   I wonder if the enumeration belongs in SECURITY-THREAT-MODEL.md instead. Variant lists drift as the codebase grows; what AGENTS.md needs is the principle ("identify the active variant before assessing reachability"). Otherwise next time a backend lands only one file gets updated and AGENTS.md lags.



##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,740 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata whose visibility is governed by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but persistence-layer
+  access by internal Polaris callsites is not by itself proof that the data may be
+  returned to an external caller or used to mutate protected state. Authorization
+  must be enforced before protected data is exposed or protected state is changed.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- Grant and role-management operations must enforce the intended grant authority
+  defined by Polaris authorization rules. A principal must not be able to obtain
+  privileges that direct checks would reject by using indirect role creation,
+  self-grants, role nesting, privilege delegation, or other second-order effects.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Within the applicable realm and configured storage-policy scope, reused,
+  overlapping, or ambiguous storage locations must not create an unintended
+  authorization bypass. Explicitly configured overlap modes, table clones, and
+  documented credential-vending scope limitations should be treated according to
+  their documented behavior, not reported solely because overlap exists.

Review Comment:
   +1 to dennishuo. As written, agents will file false-positive findings against intentional overlap-check overrides, table clones, legitimate role nesting (line 179), and internal-callsite reads that don't return data externally (line 161-164). My bias would be to land all three clarifications in this PR. Once AGENTS.md cites the model the broad invariants become the default rule, and the project can't reclassify findings already filed.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["dimas-b (via GitHub)" <gi...@apache.org>]

dimas-b commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3244596267


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.

Review Comment:
   Shouldn't access to this metadata always be restricted?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["potiuk (via GitHub)" <gi...@apache.org>]

potiuk commented on PR #4433:
URL: https://github.com/apache/polaris/pull/4433#issuecomment-4529159411

   Friendly nudge from the ASF Security team — this PR has been
   APPROVED for ~5 days (thanks @dimas-b for the review). Merging
   this lands the Polaris threat-model doc that the Glasswing scan
   pipeline reads for pre-flight, so the merge is the remaining
   gate on our side before we can queue the actual scan against
   apache/polaris. Any timeline, or anything still pending from
   our end? Happy to make changes if needed.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["snazy (via GitHub)" <gi...@apache.org>]

snazy commented on PR #4433:
URL: https://github.com/apache/polaris/pull/4433#issuecomment-4474935203

   > Overall looks pretty good, thanks for putting this together! Commented on a few places that might benefit from additional qualifiers or rewording
   
   Agree, all three are good points worth to clarify, I've pushed a commit to address that.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["RussellSpitzer (via GitHub)" <gi...@apache.org>]

RussellSpitzer commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3244306479


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal
+  authorized for one logical entity to access another logical entity's data or
+  metadata.
+- Provider policy documents and expressions must escape or otherwise safely
+  encode caller-controlled identifiers, paths, and property values.
+- User-controlled input must not be used to construct SQL, filesystem paths,
+  object-store paths, URLs, or process commands without appropriate validation or
+  safe APIs.
+- Error messages must not disclose secrets or unauthorized metadata.
+- Existence, names, and relationships of principals, roles, catalogs,
+  namespaces, tables, views, and policies must not be disclosed to unauthorized
+  callers unless that disclosure is explicitly documented and accepted.
+- Configuration changes that create, reset, rotate, store, or delete credentials
+  or secrets must be authorized, consistently applied, and must not leave stale
+  credentials or orphaned secrets with unintended access.
+- Internal and administrative APIs must not be exposed as public unauthenticated
+  APIs.
+- Optional build features, extensions, and distribution-specific packaging must
+  not weaken Polaris authentication, authorization, credential handling, or
+  metadata isolation without explicit configuration and documentation.
+
+## Security Issues
+
+The following should generally be treated as potential security vulnerabilities:
+
+- Authentication bypass.
+- Authorization bypass or privilege escalation.
+- Cross-catalog or cross-realm data access caused by missing checks.
+- Unauthorized mutation of catalog metadata, roles, policies, or principals.
+- Exposure of credentials, tokens, secrets, or sensitive configuration.
+- Exposure of secrets through client-visible properties, configuration
+  responses, logs, profiles, command output, browser storage, or generated
+  artifacts.
+- Credential-vending behavior that grants broader storage access than the
+  caller's authorized operation or effective storage boundary.
+- Storage-location validation bypasses, including unvalidated URI-bearing table
+  metadata, reused or overlapping locations, and provider-policy construction
+  issues.
+- Token or credential lifecycle issues that allow access to continue beyond the
+  intended reset, rotation, revocation, realm, or scope boundary.
+- Unauthorized disclosure of identity, role, policy, catalog, namespace, table,
+  or view existence when that existence is itself sensitive.
+- SQL injection, command injection, unsafe deserialization, server-side request
+  forgery, path traversal, or template injection reachable through untrusted
+  input.
+- Unsafe use of externally configured endpoints that can redirect privileged
+  traffic, credentials, tokens, metadata, or storage requests outside the
+  intended trust relationship.
+- Logging or returning sensitive values to unauthorized users.
+- Use of weak cryptographic validation for authentication or authorization
+  decisions.
+- Insecure defaults that expose protected APIs or disable required security
+  checks.
+
+## Non-Issues And Deployment Responsibilities
+
+The following are not normally treated as Polaris vulnerabilities by themselves:
+
+- A deployment operator choosing weak credentials or exposing the service
+  publicly without required network controls.
+- A compromised administrator using their legitimate administrative privileges.
+- A compromised database, object store, Kubernetes cluster, host operating
+  system, identity provider, or external policy decision point.
+- Lack of rate limiting unless it enables a concrete security impact beyond
+  resource exhaustion.
+- Information visible to a principal that is explicitly authorized to access it.
+- Storage-provider limitations that are accurately documented and do not give
+  Polaris callers more access than the deployment intentionally configured.
+- Test-only code, local development defaults, or example configuration not used
+  in production paths, unless clearly reachable in production builds.
+
+Polaris does not, by itself, provide the following security properties:
+
+- Protection after compromise of deployment infrastructure, persistence
+  backends, object stores, identity providers, external policy decision points,
+  Kubernetes clusters, hosts, or administrator workstations.
+- Protection against authorized administrators using their legitimate privileges
+  in ways the deployment does not intend.
+- Network isolation, TLS termination, firewalling, ingress policy, Kubernetes
+  policy, or cloud-account isolation beyond what the deployment provides.
+- Secret management for values that operators place outside Polaris-controlled
+  secret storage or configuration mechanisms.
+- Stronger delegated-credential isolation than the selected storage provider,
+  configured policy model, and documented deployment mode can support.
+- Safety of arbitrary downstream packaging, module combinations, integrations,
+  or local patches that are not part of an official Polaris artifact or
+  documented supported configuration.
+
+Deployment operators and downstream integrators are responsible for:
+
+- Protecting service credentials, signing keys, client secrets, object-store
+  credentials, identity-provider configuration, policy-service credentials, and
+  local CLI or admin-tool profiles.
+- Configuring TLS, network exposure, ingress, firewalls, service accounts,
+  Kubernetes permissions, cloud IAM, object-store policy, and persistence-backend
+  access according to the deployment's security requirements.
+- Choosing production-appropriate authentication, authorization, persistence,
+  storage, and policy-service settings before exposing Polaris to untrusted
+  clients.
+- Avoiding production use of local-development defaults, sample credentials,
+  test fixtures, example configuration, and benchmark-only tooling unless those
+  choices are explicitly intended and protected.
+- Rotating and revoking credentials, tokens, secrets, and delegated access
+  according to the deployment's operational requirements.
+- Protecting logs, generated configuration, local profiles, backups, database
+  snapshots, object-store metadata, and other artifacts that may contain
+  security-sensitive values.
+
+The following patterns often require careful triage because they can be
+vulnerabilities, documentation hardening items, deployment responsibilities, or
+false positives depending on the actor, configuration, and reachable path:
+
+- Treating client-visible properties, catalog metadata, generated configuration,
+  local profiles, command output, browser storage, or logs as secret stores.
+- Assuming delegated storage credentials are narrower than the configured
+  provider policy, access-boundary mechanism, or documented deployment mode
+  actually supports.
+- Assuming every custom build, Gradle project combination, optional dependency,
+  extension, or downstream package is an official supported Polaris artifact.
+- Applying server threat-model assumptions unchanged to CLIs, web UIs,
+  migration tools, MCP servers, synchronization tools, benchmarks, or other
+  related tools.
+- Treating test fixtures, mocked trust decisions, direct internal object
+  construction, or already-authorized access as proof of a production
+  vulnerability.
+- Treating dependency advisories as Polaris vulnerabilities without showing that
+  the vulnerable behavior is present, reachable, and crosses a Polaris trust
+  boundary.
+
+Known non-findings are cases already covered by the non-issues, dependency,
+variant, distribution, and related-tool sections above. Common examples include
+authorized access, unreachable dependency advisories, test-only behavior,
+compromised deployment infrastructure, and impossible variant combinations.
+
+## Consumption And Distribution Boundaries
+
+Users consume Polaris in several ways, including:
+
+- Release tarballs containing the runnable Quarkus applications for the Polaris
+  server and Polaris admin tool.
+- Container images for the Polaris server and Polaris admin tool.
+- Helm charts for deploying the Polaris server.
+- The Python-based CLI tool under `client/`.
+- Custom applications or distributions built from Polaris modules such as
+  `polaris-core`, `polaris-runtime-service`, extension modules, or other Gradle
+  project combinations.
+
+The Polaris threat model applies directly to artifacts and modules produced by
+the Apache Polaris project. It also applies to custom distributions when they use
+Polaris code to make authentication, authorization, catalog metadata, policy, or
+credential-handling decisions.
+
+Custom distributions can change the effective threat model. When evaluating a
+finding, determine whether the behavior is present in:
+
+- An official Polaris release artifact.
+- An official Polaris container image.
+- An official Polaris Helm chart.
+- The Polaris CLI.
+- A reusable Polaris module.
+- An optional extension or dependency enabled by build configuration.
+- Downstream-only integration code or deployment packaging.
+
+A finding in downstream-only code, private packaging, custom deployment
+configuration, or third-party integration logic is not automatically a Polaris
+vulnerability. Findings in custom distributions or downstream integrations may
+still be useful to report when they indicate a weakness in Polaris code,
+supported configuration, documented integration guidance, reusable modules,
+extension points, or official release artifacts. Such findings are evaluated case
+by case and are not automatically accepted as Polaris vulnerabilities.
+
+Building a custom distribution from an official Polaris source release can help
+establish that the affected code originates from Polaris, but it does not by
+itself make every selected module combination, optional dependency, Gradle
+property, packaging choice, or deployment configuration an official supported
+artifact.
+
+The severity and handling of a finding depend on the affected actor, protected
+asset, trust boundary, exploitability, default exposure, affected official
+artifacts, documented usage, and whether Polaris code or configuration is
+responsible for the security decision.
+
+Findings against unreleased code, including development branches such as `main`,
+may still be useful to report, but they are not automatically treated the same as
+findings affecting released Polaris artifacts. Handling depends on whether the
+issue affects released code, is likely to ship, or indicates a broader weakness
+in Polaris code, defaults, extension points, or documented guidance.
+
+## Backend And Authorization Variants
+
+Official Polaris artifacts may include multiple backend, authentication,
+authorization, storage, and extension implementations. Automated analysis should
+consider all implementations present in the artifact, but concrete findings must
+identify the coherent runtime configuration under which the behavior is
+reachable.
+
+The presence of multiple implementations in one artifact does not mean their
+runtime assumptions can be freely combined. Do not mix assumptions from
+different persistence backends, authentication modes, authorization services,
+storage providers, optional extensions, or deployment profiles unless the
+combination is supported and reachable in one deployment.
+
+Polaris behavior depends on configured persistence, authentication, and
+authorization components. Automated analysis must identify the active variant
+before assessing reachability, impact, and responsibility.
+
+Persistence backends may include JDBC, in-memory, NoSQL, test fixtures, or other
+implementations. A finding may be backend-specific when it depends on
+transaction semantics, consistency, uniqueness constraints, secret storage,
+query behavior, serialization, indexing, cleanup behavior, or backend-specific
+configuration.
+
+Authentication modes may include internal Polaris principals and secrets,
+external OIDC identity providers, or mixed configurations. A finding may be
+authentication-mode-specific when it depends on token validation, claim mapping,
+realm selection, tenant mapping, credential reset, client secrets, token
+exchange, or principal provisioning.
+
+Authorization may be enforced through internal Polaris RBAC, external policy
+decision points, Ranger, OPA, or mixed decision paths. A finding may be
+authorization-mode-specific when it depends on privilege derivation, request
+context passed to an external service, policy fallback behavior, deny/allow
+precedence, fail-open or fail-closed behavior, caching, or mismatches between
+internal and external decisions.
+
+When evaluating a finding, identify:
+
+- The persistence backend involved.
+- The authentication mode involved.
+- The authorization service or model involved.
+- Whether the behavior is common across variants or variant-specific.
+- Whether unsupported, test-only, or development-only variants are required.
+- Whether a production-supported configuration is affected.
+
+A finding may be valid when it affects:
+
+- All variants.
+- One specific supported variant.
+- A documented combination of variants.
+- An optional implementation present in an official artifact but activated only
+  by configuration.
+
+A finding is weaker, and may be a false positive, when it requires combining
+mutually exclusive runtime assumptions or test-only behavior that is not
+reachable in a supported deployment.
+
+Security invariants must hold consistently across supported variants unless a
+variant-specific limitation is explicitly documented.
+
+External authorization integrations must receive enough request context to make
+the intended decision and must fail according to documented fail-open or
+fail-closed behavior.
+
+Internal and external authorization paths must not disagree in a way that grants
+access broader than the configured policy intends.
+
+Persistence backends must preserve authorization-relevant invariants such as
+principal identity, role grants, privilege scope, catalog boundaries, credential
+state, and entity uniqueness.
+
+## Related Polaris Tools
+
+Related tools maintained by the Apache Polaris project may affect Polaris
+security when they are released, documented for user or operator use, handle
+Polaris credentials or metadata, expose reachable interfaces, or can affect a
+Polaris deployment through administration, migration, synchronization,
+credential handling, generated artifacts, or copied examples.
+
+These tools can have different audiences, deployment models, protected assets,
+and trust boundaries than the Polaris server. Evaluate findings against the
+tool-specific threat model and agent guidance in the tools repository where
+available. A finding in a related tool is not automatically a Polaris server
+vulnerability.
+
+## Upstream Dependencies
+
+Polaris depends on Apache Iceberg and other open source projects. Vulnerabilities
+in those dependencies can affect Polaris when Polaris exposes the vulnerable
+behavior through a reachable code path, depends on the vulnerable behavior for a
+security decision, ships an affected dependency in a supported distribution, or
+uses unsafe configuration that changes the impact.
+
+A dependency vulnerability is not automatically a Polaris vulnerability. When
+evaluating one, determine whether:
+
+- The vulnerable dependency code is present in a supported Polaris artifact.
+- The vulnerable behavior is reachable through Polaris.
+- Exploitation crosses a Polaris trust boundary.
+- Polaris authentication, authorization, metadata, credentials, or configuration
+  are affected.
+- Polaris needs a release, mitigation, configuration change, or advisory.
+
+Respect the upstream project's security policy and disclosure process. Do not
+include non-public upstream vulnerability details in Polaris issues, commits,
+documentation, tests, or public discussions unless the information has already
+been publicly disclosed or coordinated disclosure explicitly permits it.
+
+## Security-Relevant Documentation Findings
+
+Documentation, examples, defaults, and generated reference material can affect
+security when they shape how users deploy, configure, integrate, or operate
+Polaris.
+
+A documentation issue may be security-relevant when it could reasonably cause
+users, operators, integrators, or downstream tool authors to misunderstand a
+security boundary, protected asset, trust assumption, default behavior, supported
+configuration, operational responsibility, or security-sensitive workflow.
+
+Examples include, but are not limited to, documentation that could lead users to:
+
+- Store secrets in client-visible properties or metadata.
+- Expose protected APIs, tools, or admin interfaces unintentionally.
+- Assume credentials, tokens, storage policies, or access boundaries are
+  narrower than they are.
+- Use development-only defaults or examples in production.
+- Misunderstand authentication, authorization, role scope, realm scope, or
+  external policy behavior.
+- Configure storage, federation, identity providers, policy services, TLS, or
+  endpoints in a way that weakens intended security.
+- Miss provider-specific limitations that affect isolation or credential scope.
+
+This category applies across all Polaris areas, including server behavior,
+clients, tools, packaging, deployment, configuration, authentication,
+authorization, storage, federation, persistence backends, policy integrations,
+dependency usage, upgrade guidance, and examples.
+
+Security-relevant documentation findings are not automatically Polaris
+vulnerabilities and do not automatically require an advisory or CVE. They should
+still be reported as hardening or operator-safety findings when clearer
+documentation could prevent realistic misuse.
+
+ASF security guidance remains authoritative for whether a finding should be
+handled as an undisclosed vulnerability, advisory, CVE, normal bug, or
+documentation hardening item.
+
+When reporting such a finding, identify:
+
+- The documented behavior, example, or missing warning.
+- The security assumption a user may incorrectly make.
+- The actor, asset, or boundary affected by the misunderstanding.
+- Whether the underlying product behavior is correct, unsafe, or ambiguous.
+- Proposed safer wording or placement for the clarification.
+
+## Guidance For Automated Analysis
+
+When evaluating a potential finding:
+
+1. Identify the actor required to exploit it.
+2. Identify the protected asset affected.
+3. Identify the trust boundary crossed.
+4. Identify the missing or incorrect security invariant.
+5. Distinguish between:
+   - a vulnerability in Polaris,
+   - a deployment misconfiguration,
+   - a dependency vulnerability not exposed by Polaris,
+   - a false positive caused by test, demo, or unreachable code.
+6. Prefer findings with a concrete reachable path from an untrusted or
+   lower-privileged actor to unauthorized access, mutation, disclosure, or
+   privilege escalation.
+7. For findings involving packaging, optional dependencies, Gradle properties,
+   container images, Helm charts, or custom distributions, identify the exact
+   source revision, such as the official source release version, Git commit,
+   branch, or tag, along with the selected modules, enabled Gradle properties,
+   optional extensions, packaging format, and deployment-relevant configuration
+   before assessing reachability, supported status, and severity.
+8. For findings involving related Polaris tools, use the tool-specific threat
+   model and agent guidance where available. A finding in a related tool is not
+   automatically a Polaris server vulnerability.
+9. For findings involving storage locations or credential vending, enumerate all
+   URI-bearing inputs and metadata fields used by the operation, identify when
+   they are validated, and verify that the same effective locations are used for
+   authorization, persistence, storage access, and delegated credential scope.
+10. For findings involving properties or configuration values, classify whether
+    each value is secret, operator-visible, management-plane visible,
+    data-plane client-visible, logged, stored in local profiles, or exported to
+    generated artifacts.
+11. For findings involving tokens, principal credentials, reset, rotation, or
+    token exchange, identify the principal, realm, requested scope, effective
+    scope, expiration, revocation behavior, and whether previously issued
+    credentials or tokens can still cross the intended boundary.
+12. For findings involving existence checks, compare `not found` and
+    `forbidden` behavior and decide whether the target object's existence,
+    name, or relationship is itself a protected asset in the relevant
+    deployment.
+13. For findings involving external endpoints, federation, object stores, or
+    policy integrations, identify which party controls the endpoint, which
+    credentials or metadata are sent to it, whether transport security is
+    required, and whether redirects or custom endpoints can cross a trust
+    boundary.
+14. For variant-specific findings, do not mix assumptions from different
+    persistence backends, authentication modes, authorization services, storage
+    providers, optional extensions, or deployment profiles unless the
+    combination is supported and reachable in one coherent deployment. Identify
+    the concrete configuration under which the finding is reachable, or state
+    that the finding is common across variants.
+15. For documentation findings, separate security-relevant documentation issues

Review Comment:
   Claude flagged this as potentially being an issue because we have adjacent text here and in the next paragraph that are essentially contradictory. 
   
   > Step 15 told readers to report documentation issues in several situations. The next block said not to report things that are only “security-adjacent.” A rushed or chunked read can sound like two different rules unless it is obvious they share one usefulness bar.
   
   It suggests putting the same "useful finding" message for 15. 
   
   I don't have enough experience to know how this might misbehave so it may be fine as is.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["snazy (via GitHub)" <gi...@apache.org>]

snazy commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3244208977


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |

Review Comment:
   good point about potential agent slowdown, fixed



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["RussellSpitzer (via GitHub)" <gi...@apache.org>]

RussellSpitzer commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3244378825


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal

Review Comment:
   Claude promises it understands this line and tells me I am being overly cautious and it will be handled in triage 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Add Polaris threat model and security guidance for agents [polaris]

["RussellSpitzer (via GitHub)" <gi...@apache.org>]

RussellSpitzer commented on code in PR #4433:
URL: https://github.com/apache/polaris/pull/4433#discussion_r3244441993


##########
SECURITY-THREAT-MODEL.md:
##########
@@ -0,0 +1,730 @@
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+-->
+
+# Apache Polaris Threat Model
+
+## Purpose
+
+This document defines the security boundaries for Apache Polaris. It is intended
+to guide maintainers, security reviewers, and automated analysis tools when
+evaluating potential vulnerabilities.
+
+Use this document to decide whether a finding affects a protected Polaris asset,
+crosses a Polaris trust boundary, violates a Polaris security invariant, and
+should be handled as a Polaris security issue.
+
+This document is guidance for analysis and triage. It does not make policy
+decisions, accept or reject vulnerability reports, assign ASF severity, allocate
+CVEs, or determine disclosure handling. Human project and ASF security review is
+required for those decisions.
+
+## Scope
+
+Apache Polaris is a catalog service for managing Apache Iceberg catalogs,
+namespaces, tables, views, principals, roles, policies, and related metadata.
+
+This threat model covers:
+
+- Polaris server and runtime components.
+- REST APIs exposed by Polaris.
+- Authentication and authorization behavior.
+- Catalog metadata access and mutation.
+- Persistence-layer interactions.
+- Integration points with storage, catalog, policy, and identity backends where
+  Polaris makes authentication, authorization, or trust decisions.
+
+This threat model does not cover:
+
+- Vulnerabilities in client applications using Polaris incorrectly.
+- Compromise of the underlying database, object store, identity provider,
+  container platform, host operating system, or deployment platform.
+- Denial of service caused solely by insufficient infrastructure sizing.
+- Bugs in third-party dependencies unless Polaris exposes them through unsafe
+  configuration or usage.
+
+## Component Families
+
+Polaris has several component families with different entry points, deployment
+models, and trust boundaries:
+
+| Component family | Representative entry points | Deployment model | Threat-model scope |
+| --- | --- | --- | --- |
+| Polaris server and runtime | Management APIs, catalog APIs, service runtime | Long-running service | In scope for authentication, authorization, metadata, persistence, storage, policy, and credential-handling decisions. |
+| Polaris admin tool | Administrative CLI commands and generated local profiles | Operator tool | In scope when handling credentials, configuration, administration, logs, or generated artifacts. |
+| Python CLI under `client/python/` | Client commands, local configuration, command output | User or operator CLI | In scope when handling credentials, tokens, catalog metadata, local profiles, logs, or generated artifacts. |
+| Release artifacts | Source release, runnable tarballs, container images, Helm charts | Distribution and deployment | In scope for packaged defaults, included modules, enabled features, generated configuration, and documented deployment paths. |
+| Reusable modules | `polaris-core`, `polaris-runtime-service`, extension modules, and selected Gradle project combinations | Embedded or customized downstream use | In scope when Polaris code makes security decisions; downstream-only integration code is evaluated separately. |
+| Optional integrations | Persistence backends, authentication modes, authorization services, storage providers, federation, and optional extensions | Runtime-selected or build-enabled features | In scope for coherent supported configurations; findings must identify the active variant and relevant configuration. |
+| Related Polaris tools | Tools published from `apache/polaris-tools` and referenced by the Polaris project or website | Developer, operator, migration, synchronization, MCP, benchmark, or web UI tools | Evaluated with tool-specific audience, deployment model, protected assets, and trust boundaries; not automatically Polaris server vulnerabilities. |
+
+## System Overview
+
+Polaris accepts requests from clients, authenticates callers through configured
+authentication mechanisms, authorizes operations against Polaris roles,
+privileges, policies, and catalog metadata, and persists metadata through the
+configured persistence backend.
+
+Polaris may integrate with external systems, including identity providers,
+object stores, policy decision points, catalog backends, and deployment
+infrastructure. These systems can affect Polaris security when Polaris relies on
+their output for authentication, authorization, routing, or persistence
+decisions.
+
+## Actors And Roles
+
+- Anonymous caller: A caller without valid authentication.
+- Authenticated principal: A valid user or service principal known to Polaris.
+- Catalog user: An authenticated principal with privileges on one or more
+  catalog resources.
+- Catalog administrator: A principal with administrative privileges over a
+  catalog.
+- Realm administrator: A principal with administrative privileges over the
+  Polaris realm.
+- Deployment operator: A person or system with access to deploy, configure, or
+  operate Polaris infrastructure.
+- External identity provider: A trusted authentication authority configured by
+  the deployment.
+- External policy decision point: A configured authorization service that may
+  participate in Polaris access decisions.
+- Persistence backend: The configured database or storage system used by
+  Polaris.
+
+## Protected Assets
+
+Polaris treats the following as security-sensitive:
+
+- Authentication credentials, bearer tokens, client secrets, signing keys, and
+  refresh tokens.
+- Principal, role, privilege, and policy metadata.
+- Principal, principal-role, and catalog-role names when a deployment treats
+  identity or role names as sensitive or personal data.
+- Catalog, namespace, table, and view metadata where access is restricted by
+  Polaris authorization.
+- Storage locations, table locations, metadata locations, manifest locations,
+  statistics locations, and other URI-bearing metadata that define where
+  catalog-managed data or metadata resides.
+- Temporary or delegated storage credentials, scoped storage policies,
+  credential access boundaries, session policies, and provider-specific policy
+  expressions.
+- Configuration values that affect authentication, authorization, token
+  validation, policy evaluation, credential vending, storage boundaries,
+  federation, or backend connectivity.
+- Audit-relevant request identity and authorization context.
+
+## Trust Boundaries
+
+Polaris assumes the following boundaries:
+
+- Network callers are untrusted until authenticated.
+- Authenticated principals are not inherently trusted to access resources; every
+  protected operation must pass authorization.
+- Request-provided identifiers, catalog names, namespace names, table names,
+  view names, role names, policy names, and principal names are untrusted input.
+- Identity-provider claims are trusted only after token validation according to
+  the configured authentication mechanism.
+- External policy decisions are trusted only according to the configured policy
+  integration and the request context Polaris supplies to that integration.
+- Management-plane APIs, catalog data-plane APIs, admin tools, and client tools
+  may expose different metadata and require separate authorization checks.
+- Catalog properties, entity properties, and configuration values may cross from
+  management-plane configuration into data-plane client-visible responses; they
+  must be classified by intended visibility before storing sensitive values.
+- Credential vending crosses from Polaris authorization into object-store or
+  external-system authorization; delegated credentials must be scoped to the
+  authorized actor, operation, and storage locations.
+- Storage locations and URI-bearing metadata cross from Polaris metadata into
+  object stores, metastores, filesystems, or external catalogs; caller-supplied
+  locations are untrusted until validated against the effective storage policy.
+- Provider-specific storage policy expressions, IAM policies, access boundaries,
+  and session policies are security boundaries and must safely encode
+  caller-controlled identifier or path material.
+- Externally configured endpoints, federation targets, identity-provider
+  metadata, object-store endpoints, and catalog backends are trusted only for
+  the configured purpose and must not silently redirect secrets or privileged
+  requests outside that trust relationship.
+- Persistence backends are trusted to store and return data, but Polaris must not
+  rely on callers to enforce authorization before persistence access.
+- Deployment operators are trusted with configuration and infrastructure-level
+  secrets.
+
+## Security Invariants
+
+The following properties must hold:
+
+- Protected API operations require authentication unless explicitly documented as
+  public.
+- Authorization checks must be performed before returning or mutating protected
+  catalog metadata.
+- A principal must not be able to grant itself privileges it does not already
+  have authority to grant.
+- Role, privilege, and policy changes must not bypass scope restrictions.
+- Realm, catalog, namespace, table, and view identifiers must not allow access
+  across authorization boundaries.
+- Token issuance, token exchange, credential reset, and credential rotation must
+  preserve the intended principal, realm, role scope, expiration, and revocation
+  semantics.
+- Tokens, credentials, and secrets must not be logged, returned in API
+  responses, or persisted in plaintext unless explicitly required and protected
+  by deployment controls.
+- Properties and configuration values that are returned to clients must be
+  treated as client-visible and must not be used as a secret store.
+- Storage locations and URI-bearing metadata must be validated against the
+  effective catalog, namespace, table, and storage-policy boundaries before they
+  are persisted, used to access storage, or used to mint delegated credentials.
+- Credential vending must not occur before the relevant location, authorization,
+  and scope checks have completed.
+- Temporary storage credentials must be scoped as narrowly as the configured
+  storage provider and documented mode allow. Provider-specific limitations that
+  broaden scope must be explicit to operators.
+- Reused, overlapping, or ambiguous storage locations must not allow a principal
+  authorized for one logical entity to access another logical entity's data or
+  metadata.
+- Provider policy documents and expressions must escape or otherwise safely
+  encode caller-controlled identifiers, paths, and property values.
+- User-controlled input must not be used to construct SQL, filesystem paths,
+  object-store paths, URLs, or process commands without appropriate validation or
+  safe APIs.
+- Error messages must not disclose secrets or unauthorized metadata.
+- Existence, names, and relationships of principals, roles, catalogs,
+  namespaces, tables, views, and policies must not be disclosed to unauthorized
+  callers unless that disclosure is explicitly documented and accepted.
+- Configuration changes that create, reset, rotate, store, or delete credentials
+  or secrets must be authorized, consistently applied, and must not leave stale
+  credentials or orphaned secrets with unintended access.
+- Internal and administrative APIs must not be exposed as public unauthenticated
+  APIs.
+- Optional build features, extensions, and distribution-specific packaging must
+  not weaken Polaris authentication, authorization, credential handling, or
+  metadata isolation without explicit configuration and documentation.
+
+## Security Issues
+
+The following should generally be treated as potential security vulnerabilities:
+
+- Authentication bypass.
+- Authorization bypass or privilege escalation.
+- Cross-catalog or cross-realm data access caused by missing checks.
+- Unauthorized mutation of catalog metadata, roles, policies, or principals.
+- Exposure of credentials, tokens, secrets, or sensitive configuration.
+- Exposure of secrets through client-visible properties, configuration
+  responses, logs, profiles, command output, browser storage, or generated
+  artifacts.
+- Credential-vending behavior that grants broader storage access than the
+  caller's authorized operation or effective storage boundary.
+- Storage-location validation bypasses, including unvalidated URI-bearing table
+  metadata, reused or overlapping locations, and provider-policy construction
+  issues.
+- Token or credential lifecycle issues that allow access to continue beyond the
+  intended reset, rotation, revocation, realm, or scope boundary.
+- Unauthorized disclosure of identity, role, policy, catalog, namespace, table,
+  or view existence when that existence is itself sensitive.
+- SQL injection, command injection, unsafe deserialization, server-side request
+  forgery, path traversal, or template injection reachable through untrusted
+  input.
+- Unsafe use of externally configured endpoints that can redirect privileged
+  traffic, credentials, tokens, metadata, or storage requests outside the
+  intended trust relationship.
+- Logging or returning sensitive values to unauthorized users.
+- Use of weak cryptographic validation for authentication or authorization
+  decisions.
+- Insecure defaults that expose protected APIs or disable required security
+  checks.
+
+## Non-Issues And Deployment Responsibilities
+
+The following are not normally treated as Polaris vulnerabilities by themselves:
+
+- A deployment operator choosing weak credentials or exposing the service
+  publicly without required network controls.
+- A compromised administrator using their legitimate administrative privileges.
+- A compromised database, object store, Kubernetes cluster, host operating
+  system, identity provider, or external policy decision point.
+- Lack of rate limiting unless it enables a concrete security impact beyond
+  resource exhaustion.
+- Information visible to a principal that is explicitly authorized to access it.
+- Storage-provider limitations that are accurately documented and do not give
+  Polaris callers more access than the deployment intentionally configured.
+- Test-only code, local development defaults, or example configuration not used
+  in production paths, unless clearly reachable in production builds.
+
+Polaris does not, by itself, provide the following security properties:
+
+- Protection after compromise of deployment infrastructure, persistence
+  backends, object stores, identity providers, external policy decision points,
+  Kubernetes clusters, hosts, or administrator workstations.
+- Protection against authorized administrators using their legitimate privileges
+  in ways the deployment does not intend.
+- Network isolation, TLS termination, firewalling, ingress policy, Kubernetes
+  policy, or cloud-account isolation beyond what the deployment provides.
+- Secret management for values that operators place outside Polaris-controlled
+  secret storage or configuration mechanisms.
+- Stronger delegated-credential isolation than the selected storage provider,
+  configured policy model, and documented deployment mode can support.
+- Safety of arbitrary downstream packaging, module combinations, integrations,
+  or local patches that are not part of an official Polaris artifact or
+  documented supported configuration.
+
+Deployment operators and downstream integrators are responsible for:
+
+- Protecting service credentials, signing keys, client secrets, object-store
+  credentials, identity-provider configuration, policy-service credentials, and
+  local CLI or admin-tool profiles.
+- Configuring TLS, network exposure, ingress, firewalls, service accounts,
+  Kubernetes permissions, cloud IAM, object-store policy, and persistence-backend
+  access according to the deployment's security requirements.
+- Choosing production-appropriate authentication, authorization, persistence,
+  storage, and policy-service settings before exposing Polaris to untrusted
+  clients.
+- Avoiding production use of local-development defaults, sample credentials,
+  test fixtures, example configuration, and benchmark-only tooling unless those
+  choices are explicitly intended and protected.
+- Rotating and revoking credentials, tokens, secrets, and delegated access
+  according to the deployment's operational requirements.
+- Protecting logs, generated configuration, local profiles, backups, database
+  snapshots, object-store metadata, and other artifacts that may contain
+  security-sensitive values.
+
+The following patterns often require careful triage because they can be
+vulnerabilities, documentation hardening items, deployment responsibilities, or
+false positives depending on the actor, configuration, and reachable path:
+
+- Treating client-visible properties, catalog metadata, generated configuration,
+  local profiles, command output, browser storage, or logs as secret stores.
+- Assuming delegated storage credentials are narrower than the configured
+  provider policy, access-boundary mechanism, or documented deployment mode
+  actually supports.
+- Assuming every custom build, Gradle project combination, optional dependency,
+  extension, or downstream package is an official supported Polaris artifact.
+- Applying server threat-model assumptions unchanged to CLIs, web UIs,
+  migration tools, MCP servers, synchronization tools, benchmarks, or other
+  related tools.
+- Treating test fixtures, mocked trust decisions, direct internal object
+  construction, or already-authorized access as proof of a production
+  vulnerability.
+- Treating dependency advisories as Polaris vulnerabilities without showing that
+  the vulnerable behavior is present, reachable, and crosses a Polaris trust
+  boundary.
+
+Known non-findings are cases already covered by the non-issues, dependency,
+variant, distribution, and related-tool sections above. Common examples include
+authorized access, unreachable dependency advisories, test-only behavior,
+compromised deployment infrastructure, and impossible variant combinations.
+
+## Consumption And Distribution Boundaries
+
+Users consume Polaris in several ways, including:
+
+- Release tarballs containing the runnable Quarkus applications for the Polaris
+  server and Polaris admin tool.
+- Container images for the Polaris server and Polaris admin tool.
+- Helm charts for deploying the Polaris server.
+- The Python-based CLI tool under `client/`.
+- Custom applications or distributions built from Polaris modules such as
+  `polaris-core`, `polaris-runtime-service`, extension modules, or other Gradle
+  project combinations.
+
+The Polaris threat model applies directly to artifacts and modules produced by
+the Apache Polaris project. It also applies to custom distributions when they use
+Polaris code to make authentication, authorization, catalog metadata, policy, or
+credential-handling decisions.
+
+Custom distributions can change the effective threat model. When evaluating a
+finding, determine whether the behavior is present in:
+
+- An official Polaris release artifact.
+- An official Polaris container image.
+- An official Polaris Helm chart.
+- The Polaris CLI.
+- A reusable Polaris module.
+- An optional extension or dependency enabled by build configuration.

Review Comment:
   Assuming this only counts for released source artifacts but that should probably be implied



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org