Apache Polaris Service Principals: Machine Identity, Secret Rotation, and Least Privilege

A Polaris service principal gives an application or engine its own identity instead of borrowing a persons credentials. Give each workload a separate principal, map it to narrowly scoped principal roles, grant only the catalog roles it needs, store secrets in a managed secret system, and rotate credentials with an overlap window that proves both old and new clients behave as expected. This article shows how to create principals, enforce least privilege, rotate secrets safely, audit assignments, and operate these identities at scale.

Why service principals for Polaris

Service principals are machine identities. In Polaris they let automated agents, query engines, and CI systems call the catalog and act under a distinct principal. That separation gives you auditability, fine-grained role assignment, and independent rotation. If a humans account is compromised you do not have to rotate every consuming service, and if a services credentials leak you can revoke that one principal without impacting human users. These advantages become operationally decisive once you manage tens or hundreds of independent engines across clusters like the authentication test environment and the upgrade test environment.

Be explicit: a shared principal destroys workload-level accountability. If multiple services reuse the same principal, you lose the ability to trace actions back to a single workload. That makes incident response and compliance records noisy and slower.

Overview: identities, roles, and the catalog

Polaris separates authentication from authorization. Authentication establishes a principals identity. Authorization maps that identity to principal roles and catalog roles. Principal roles control Polaris-level privileges, for example the ability to create catalogs or manage role assignments. Catalog roles control access to catalog objects like datasets and sources.

Polaris currently supports external identity providers and the CLI. For external identity provider integration and developer notes, consult the Polaris external IDP developer notes and the access control documentation for Polaris 1.8.0. If you use the CLI, watch unreleased CLI command behavior because commands in unreleased documentation may change.

Diagram: service-principal trust chain

The trust chain shows where a service principal sits. The principal asserts itself to Polaris, Polaris validates the assertion (via local verification, a token signing key, or an external IDP), then Polaris issues an authorization decision based on principal roles, which map to catalog roles. The decisions then determine allowed catalog operations and the audit events written to the catalog. Use this chain to reason where you need key protection and logging. For external IDPs, the token issuance point is the highest risk area. For CLI-created static credentials, the Polaris vault of platform secrets (or your secrets manager) must be strictly controlled.

Design principles and decision points

These are the practical rules I apply when designing service principal-based access:

• One principal per workload. Separate a single engine instance, CI job type, or microservice into its own principal. If an engine runs on several clusters, give each cluster-specific principal so you can rotate or revoke per cluster.
• Map narrow principal roles, then assign only the needed catalog roles. Principal roles are Polaris-level privileges; catalog roles are dataset and source privileges.
• Prefer short-lived tokens from an external IDP when available. If you must use long-lived static credentials, place them in a secrets manager and limit their lifetime via rotation and automated revocation policies.
• Use an overlap window during rotation. The new credential must be validated while the old credential remains valid, then revoke the old credential after operational checks pass.

Each choice has operational consequences. Short-lived tokens reduce blast radius but add dependency on the IDP availability and token vending path. Long-lived static credentials simplify offline bootstrapping but require a stricter secret lifecycle. Map these tradeoffs to your incident response plan and SLOs.

Worked example: create a service principal

This example follows documented Polaris 1.8.0 access-control concepts. Consult the Polaris command line documentation for unreleased CLI changes if you use the in-development CLI features.

Goal: create a principal for an ETL engine instance on the authentication test environment that can read two datasets and register temporary jobs, but cannot modify other catalog roles. High level steps:

• Create a principal identity in Polaris, either by creating a service principal locally or registering the client in your external IDP. If you use an external IDP, configure Polaris to accept the IDP claims. For details on IDP integration, see the Polaris IDP developer notes for 1.8.0.
• Create a principal role in Polaris that grants only the Polaris-level privileges required, for example the ability to create ephemeral contexts, and bind it to the new principal.
• Create or reuse catalog roles (dataset-reader, job-submitter) and grant them only to this principal role within the catalog.
• Store the principals credentials or token vending configuration in your secrets manager and restrict access to the engines runtime service account.

Concrete CLI-like steps, adapted to available 1.8.0 commands. Verify the exact flags against the Polaris CLI documentation for your release, because CLI commands in unreleased documentation may change.

<!-- wp:code --><code># Create a principal object, name: etl-engine-b02
polaris principal create --name etl-engine-b02 --type service

# Create a principal role with minimal Polaris privileges
polaris principal-role create --name etl-job-runner --privileges 'create_context'

# Bind role to principal
polaris principal-role bind --principal etl-engine-b02 --role etl-job-runner

# Create catalog roles or use existing ones (dataset-reader, job-submitter)
polaris catalog-role create --catalog finance --name dataset-reader
polaris catalog-role grant --catalog finance --role dataset-reader --privilege read

# Bind catalog role to principal role within the catalog
polaris catalog-role bind --catalog finance --role dataset-reader --principal-role etl-job-runner
</code><!-- /wp:code -->

Note: Commands above mirror typical Polaris CLI patterns. Check the Polaris 1.8.0 command reference and the in-development CLI page because behavior and flags in unreleased documentation may change. For a conceptual discussion of how engines talk to the catalog and what the REST API surfaces, see the Dremio blog post about the Polaris REST API. That post explains how engine-to-catalog flows interact with principal authentication and authorization.

Least-privilege role graph

The least-privilege role graph is the working map you build during design. At the center are principal roles, which carry Polaris-level privileges. Edges connect principal roles to catalog roles and to the principals they govern. Catalog roles then grant specific dataset and source privileges. Keep graphs small and avoid role explosion by following these rules:

• Model by function, not by individual principal. Use the same principal role for identical workload types, for example "analytics-read-only" for all read-only analytics engines. That reduces the number of distinct role objects you must maintain.
• Do not grant more than one Polaris admin-level privilege to a service principal unless the service requires it. Administrative privileges should be audited and timebound.
• Where possible, use catalog-scoped role bindings to limit grants to specific catalogs. This prevents accidental cross-catalog access if a principal later gets additional rights at the Polaris-level.

Operational consequence: a design that uses many narrowly-scoped principal roles simplifies revocation and analysis, but increases role management overhead. Balance this with automation that can create and bind roles as part of deployment pipelines.

Worked example: rotate credentials with overlap

Rotation must be safe. The hard failure I have seen in production is rotating a credential, revoking the old one immediately, and discovering a subset of clients still using the cached old token for a minute or two. Those clients fail queries, and operators scramble to reconfigure or restart dozens of engine instances.

Goal: rotate the ETL engines secret for etl-engine-b02 with a two-hour overlap window. We will create the new secret, configure a subset of engines to fetch it, verify successful operations, then revoke the old secret.

Steps:

• Create a new credential in your secrets manager or request a new short-lived token from your IDP.
• Deploy the new credential to a canary group of engine instances. For example, pick 5% of runners or one node per cluster, here across the authentication test environment and the upgrade test environment so you exercise both clusters networking and token vending flows.
• Monitor operations for the canary. Verify three things: the engines can connect to the catalog, they can read and write expected data, and audit logs show the new principal identity is used. Track both success rates and error classes.
• If the canary is healthy, roll out to the rest of the fleet in stages. Maintain the old credential valid during the rollout window.
• After the rollout and a stabilization period, revoke the old credential. Rotation is incomplete until old credentials are revoked and tested. If revocation introduces failures, roll back to the previous credential and investigate token caching in clients.

Concrete commands depend on your secrets manager and whether Polaris is issuing tokens. Example sequence for a static secret stored in a vault. Replace vault CLI calls with the manager you use.

<!-- wp:code --><code># Create new secret version in your secret store (pseudo command)
vault kv put secret/polaris/etl-engine-b02 [email protected]

# Update canary engine configuration to reference new secret version
# (This is a deployment step, not a Polaris command.)

# After canary validation, update all engines to pull new secret version
# Monitor for auth errors; then revoke old secret version
vault kv metadata delete secret/polaris/etl-engine-b02 --versions 1
</code><!-- /wp:code -->

Important cautions: a rotation that leaves old credentials valid is not finished until the old credential is revoked. Also, CLI commands in unreleased documentation may change, so verify the exact revocation or metadata commands for your secret manager. If you rely on an IDP with token exchange, verify the IDPs token lifetime and support for forced revocation of refresh tokens.

Failure modes and mitigations

Here are the common failure modes I have seen with machine identities, and concrete mitigations.

• Clients cache old tokens and fail for a short period after rotation. Mitigation: use an overlap window with staggered rollouts, and measure client token refresh behavior during testing.
• Shared principals mask the real source of changes. Mitigation: refuse shared principals for production workloads. If you must share, add additional logging at the service layer and limit the principal to an environment-specific catalog role.
• Unreleased CLI flags differ from what you deploy. Mitigation: test CLI invocations against the Polaris release you run. Document versioned commands and annotate any in-development commands used for lab work.
• Accidental privilege escalation through broad catalog role grants. Mitigation: use catalog-scoped bindings and perform a pre-deployment role impact analysis that enumerates assets reachable by the role.
• Secrets manager misconfiguration allowing unauthorized read. Mitigation: enforce least privilege on the secret path, enable secret access logging, and rotate access credentials for the manager itself on a schedule.

These mitigations are operational. For example, if you run engines on clusters the authentication test environment and the upgrade test environment, include cross-cluster failover tests so you know what breaks when a secret is revoked and reissued only on one cluster.

Audit and compliance: audit principal and role assignments

Auditing is twofold: (1) who can act as which principal, and (2) what catalog privileges those principals have. Polaris records role binds and catalog grants. You need to query the catalog and your external audit pipeline to produce an inventory.

Worked example: produce a report that lists principals, their bound principal roles, and catalog roles they can exercise.

<!-- wp:code --><code># Pseudocode: query Polaris to list principals and bindings
polaris principal list --output json > principals.json
polaris principal-role list --output json > principal_roles.json
polaris catalog-role list --catalog finance --output json > catalog_roles_finance.json

# Join these outputs in a script to produce an inventory
python3 build_principal_inventory.py --principals principals.json --roles principal_roles.json --catalog catalog_roles_finance.json
</code><!-- /wp:code -->

Design your inventory to answer these questions for auditors and operators: which principals have admin-level Polaris privileges; which principals have cross-catalog grants; which principals are unused for longer than your dormancy policy. These are the inputs for the dormant identity review loop.

Dormant identity review loop

Service principals accumulate over time. Run a periodic dormant identity review to reclaim unused identities and tighten your attack surface. The loop has four steps:

1. Inventory principals and their last activity timestamp. Polaris audit logs and your centralized logs provide activity indicators.
2. Score principals by risk: admin privilege, cross-catalog grants, age, and last use.
3. For medium-risk principals, place a 30-day notice state where the principal continues to work but operators are notified to confirm intended use. For high-risk or high-privilege principals that show no recent use, automatically restrict privileges until reactivation is validated.
4. After the notice period, delete or disable the principal if no owner confirms the need. Record the change and allow a rollback path that re-issues credentials for legitimate but interrupted workloads.

Operationally this loop needs automation. Run the inventory and scoring monthly, and implement programmatic notices via tickets or email. Track the outcomes and look for patterns, for example a repeated set of principals that become dormant 60 days after creation may indicate a provisioning script that leaks identities.

What to measure after deployment

Define metrics up front. These are the ones that matter for machine identities in Polaris.

• Authentication success rate per-principal, per-cluster. A drop in success rate often indicates expired credentials or token vending issues. Measure per cluster, for example the authentication test environment and the upgrade test environment, so you catch cluster-scoped problems.
• Average time to rotate a credential, measured from creating the new secret to revoking the old one. Aim for predictable windows that fit maintenance windows.
• Number of principals with admin-level privileges. Track this as a rolling count and aim to reduce it.
• Percentage of principals with last-use older than your dormancy threshold. Trending upward means entitlement creep.
• Mean time to recover from a failed rotation. This measures the impact of token caching and orchestration fragility.

Log samples and audit events should be collected centrally. Make sure your alerting thresholds are practical. For example, a 1% increase in authentication failures across a fleet of 200 nodes is a meaningful signal, do not set thresholds at a much higher level where you miss early issues.

Practical rollout checklist

1. Inventory existing principals and classify by owner and privilege.
2. Define principal naming conventions that include environment and cluster, for example etl-engine-b02. This makes revocation decisions easier.
3. Create principal roles by function, then bind to principals during provisioning pipelines.
4. Integrate secrets distribution into your runtime environment, and restrict secret access to the runtime service account only.
5. Implement rotation with an overlap window and a staged rollout. Plan canary groups and test cross-cluster behavior on the authentication test environment and the upgrade test environment.
6. Automate inventory, dormant identity reviews, and periodic audits. Export reports for compliance reviewers.
7. Run tabletop incident response drills that simulate credential revocation and rotation failures.

Keep a checklist entry that reminds operators: rotation is incomplete until old credentials are revoked and tested.

Cross-links and further reading

Two Dremio pieces are useful while implementing these controls. The Dremio blog post about access control in Apache Polaris, RBAC and credential vending, gives practical context for how Polaris supports credential vending patterns. The Dremio article on the Polaris REST API explains how engines talk to the catalog, which helps when you test your credential flows and audit events. For a beginners overview of Polaris itself, the Dremio guide on "What is Apache Polaris" is a short conceptual reference. Use those pages to connect operational decisions here to the broader Polaris architecture and engine interactions.

Implementation and evaluation sequence

Follow this sequence when you introduce service principals to a production environment. Each step includes verification signals and rollback actions where applicable.

1. Plan and name. Produce a principal naming convention and a role taxonomy. Verification: review by security and platform teams. Rollback: none, this is planning.
2. Provision minimal principals in a staging environment. Verification: principals can authenticate and are in audit logs. Rollback: delete principals created for test.
3. Bind catalog roles and enforce least privilege. Verification: run queries from the principal that should succeed and queries that should fail. Rollback: adjust role bindings.
4. Integrate secrets manager and run a canary rotation. Verification: canary engines switch credentials without failures. Rollback: keep old credentials available until canary passes.
5. Roll out to production in stages across clusters, monitoring the metrics listed earlier. Verification: no spike in auth failures, canary success rates mirror global rollouts. Rollback: use staged deployment tooling to revert to previous configuration.
6. Automate inventory and dormant identity reviews. Verification: automated reports show expected principals and owners. Rollback: restore prior state from audit snapshots if automation misclassifies identities.

Labeling freshness

Facts checked on October 27, 2026: links and behavior referenced from Polaris 1.8.0 access control and the Polaris external IDP developer notes reflect the documented behavior of that release. The Polaris in-development CLI documentation may change; verify CLI flags against the release you run.

Operational runbook: stepwise implementation and safety checks

This section gives a step by step runbook you can follow in a staging environment for the three required examples: creating a service principal, rotating credentials with overlap, and auditing principal and role assignments. The steps assume Polaris CLI behavior documented as of releases/1.8.0 and in-development CLI notes. Verify command names and flags against your Polaris installation before running any commands.

Before you begin, snapshot current state. Export role bindings and principal metadata to a file and store it outside Polaris. That gives you a rollback reference if you need to re-create a principal or rebind roles.

1) Create a service principal, instrumented

Goal: create a machine identity with minimal roles, capture credentials and a test token, and validate functional access. This reproduces the worked example but adds explicit verification steps and safety assertions.

• Step 1, prepare a short-lived test environment: pick a dedicated staging catalog object and dataset you can safely query. Create a small test dataset if needed.
• Step 2, create the principal using the documented CLI. If your Polaris install is using the in-development CLI, verify the subcommands match the published in-dev notes. After creation, export the principal JSON to a file outside Polaris.
• Step 3, assign the minimum role needed to run the intended operation. Use the least-privilege role graph you already designed. Record the role assignment command output.
• Step 4, issue credentials. If Polaris supports short-lived tokens for machine identities in your version, generate one for the test run. If you must use static credentials, store them in your secret manager immediately and mark them as staging credentials.
• Step 5, run a basic functional test from the intended engine or client. For example, run the single query or metadata read the workload needs. Capture timings, response codes, and the exact request that used the credential. Keep the test load minimal so you do not affect other users.
• Step 6, assert success criteria: the principal must be able to perform the intended action, nothing more. Attempt a higher privilege action the principal should not have, such as writing or accessing a different dataset. It must fail with an access denied error. Record the error text and HTTP code or Polaris CLI exit code.
• Step 7, save artifacts: principal JSON, role binding JSON, token or credential receipt, functional test logs. Store them in your secure staging audit bucket.

Decision points to verify during this run: confirm whether your Polaris deployment enforces time-based token expiry on machine identities, and whether role bindings propagate immediately or require a cache flush. If either behavior is different from your expectations, record it and adjust your production plan.

2) Rotate credentials with overlap, reproducible

This expands the worked example into a scriptable sequence you can run against a staging principal. The important rules: never delete the old credential until the new credential has been validated by the actual workload, and treat rotation as incomplete until the old credential is revoked and no longer accepted.

• Step A, pick your overlap window. A conservative starting point is 10 minutes for short-lived tokens and 1 hour for static credentials. Tune this after you run measurement experiments below.
• Step B, add a second credential to the principal. Use the Polaris CLI behavior in your version to create a second credential or token. Export its ID so you can target it for revocation later.
• Step C, update the workload to use the new credential. If the workload reads credentials from a secret manager, push the new secret and restart the process that refreshes secrets. For processes that cache credentials, perform a graceful restart rather than a stop start. Capture the timestamp when the workload first attempts to use the new credential.
• Step D, validate the workload is functioning with the new credential. Repeat the functional test from the create runbook. Log the exact success time and any transient failures.
• Step E, revoke the old credential only after you have validated stable success and allowed your overlap window. Use a planned, logged revocation command. Immediately after revocation, run the workload test again to confirm the old credential no longer succeeds.
• Step F, soft monitor for 24 to 72 hours depending on workload criticality. Watch for authentication failures in engine logs and for increased error rates or latencies in your metrics.

Practical tip: if you use a secrets platform with versioned secrets, stage the new secret version and roll the version pointer only after validation. This avoids touching application config and reduces restart jitter.

3) Audit principal and role assignments, with evidence

This section turns the audit example into an automated verification that you can run regularly. The goal is an auditable report that links principals, their active credentials, role bindings, and last-use evidence.

• Step 1, build an inventory, export principals and role bindings from Polaris to JSON. Include credential metadata such as creation time and last rotation time when available.
• Step 2, collect last-use evidence. Combine Polaris audit logs with engine access logs to produce a last-authentication timestamp for each principal. If your Polaris version and deployment include an audit principal feature, include those entries. Correlate by principal ID and credential ID when credentials are logged.
• Step 3, compute exposure signals. For each principal, calculate the number of roles, the union of granted actions, age of oldest credential, and time since last use. Flag principals for review when they have more than X roles, where X is a policy decision. A reasonable starting policy is flagging principals with more than three roles or credentials older than 90 days.
• Step 4, produce a human readable report. Include the principal ID, assigned roles, last-use timestamp, credential age, and a short decision recommendation: continue, rotate, revoke, or review binding. Store the report in your compliance archive.
• Step 5, automate remediation runbooks for common flags. For example, for principals with long-unused credentials create a draft revocation plan that includes notification to owners and a safe rollback path.

Note: in some Polaris versions, audit events may not include credential identifiers. If that is true for your deployment, record what to verify in the audit: are you able to link a login event to a credential? If not, plan compensating controls such as more frequent credential rotation and stricter credential age policies.

Failure injection tests for service-principal workflows

Runbooks are necessary, but failure injection proves they work. Below are targeted tests to validate your create, rotate, and audit procedures. Run these in staging and automate as part of your CI pipeline for infra changes.

Test 1, credential compromise simulation

• Action: mark an active credential as compromised and revoke it immediately. Do not rotate first. Observe how quickly affected workloads fail and how your monitoring alerts.
• Expected: workloads using that credential should fail authentication after revocation. Your incident playbook should include a rollback to a secondary credential or a rapid rotation path we documented above. If your workloads continue to authenticate, investigate your revocation mechanism and caching layers.

Test 2, rotation race and overlap insufficiency

• Action: carry out a rotation with a deliberately short overlap window, for example 30 seconds for a static credential. Observe whether any requests fail during the switch.
• Expected: you will likely see transient failures. Use this test to calibrate a safe overlap for each workload type. Record failed request rates and user impact to set production overlap windows.

Test 3, role revocation propagation

• Action: remove a role from a principal and attempt the action that role allowed immediately and after a short wait. Repeat with different engine caches, if applicable.
• Expected: you should see immediate or near-immediate denial. If you observe continued access, identify where cached authorizations exist, and whether a cache flush, engine restart, or longer TTL is required to enforce revocations.

Each failure injection should end with a blameless postmortem: timeline, impact, root cause, and corrective actions. If revocation or rotation behavior differs by Polaris version, label those findings so operators know which versions require compensating controls.

Operational metrics and dashboards to track after deployment

This section lists concrete metrics to collect, how to compute them, and acceptable alert thresholds to detect problems early. These metrics map directly to the create, rotate, and audit workflows we expanded above.

• Authentication success rate per principal, computed as successful authentications divided by total authentication attempts over a 5 minute window. Alert if a critical principal falls below 99.9 percent for 15 minutes. This catches rotation misses and leaked credentials being revoked.
• Credential age distribution, histogram of credential ages across all principals. Alert if the p90 credential age exceeds your policy, for example 90 days. Use this to drive rotation cadence.
• Time to validate new credential, the time from provisioning a new credential to the first successful use by the workload. Track median and p95. If p95 is large, your rotation overlap must be increased.
• Post-revocation acceptance rate, percentage of requests accepted using a revoked credential during the first hour after revocation. Ideally this is zero. Any nonzero value indicates caching or propagation issues.
• Role change propagation time, measured from role revocation request to first denied attempt that previously succeeded. Track per engine type if you run multiple engines. Alert if p95 exceeds an operational threshold such as 2 minutes for interactive workloads.
• Principals with no recent activity, count of principals with last-use older than your dormant policy. Alert for a sudden rise, which might indicate script churn or orphaned principals from completed projects.

Dashboard layout recommendations: top row, authentication success rates and post-revocation acceptance rate. Middle row, credential age and time to validate new credential. Bottom row, inventory heatmap showing principals by role count and last-use. Use links from dashboard tiles to the raw audit logs and to the principal JSON export from Polaris for rapid investigation.

Measurement caveat: some Polaris versions and deployments may not log credential identifiers in authentication events. If your logs lack that granularity, you cannot compute post-revocation acceptance rate precisely. Instead, measure related signals like overall auth failure spikes after revocation and engine-level caches checked during failure injection tests.

Label checked on October 27, 2026: the Polaris CLI and access-control behavior referenced in this article correspond to Polaris release 1.8.0 documentation and the in-development command line notes. Confirm command names and flags against your running version before automation.

FAQ

How do I choose between short-lived tokens and static credentials?

Choose short-lived tokens when your IDP and runtime environment can reliably vend tokens and tolerate the IDPs availability constraints. Use static credentials when you need offline bootstrapping or your clients cannot refresh tokens. If you use static credentials, place them in a secrets manager and enforce rotation and strict access controls.

Can I share a principal across multiple engines?

Technically yes, but do not do that for production workloads. Shared principals destroy workload-level accountability and complicate incident response. If you must share, scope catalog roles narrowly and document the sharing rationale and owner.

What is a safe rotation overlap window?

There is no universal number. Pick an overlap that covers token caching behavior in your clients plus deployment propagation time. In practice I use an overlap between 30 minutes and 4 hours, depending on client caching semantics and cluster size. Measure actual client refresh patterns and adjust.

How do I verify role bindings do not grant excessive access?

Perform negative tests in staging: attempt access to datasets the role should not reach, and verify those requests fail. Create an automated test that enumerates dataset access attempts and compares results to an expected allowlist.

What logs should I collect for auditing?

Collect Polaris audit logs showing authentication and authorization decisions, your secret manager access logs, and engine-side logs that show which principal was used. Correlate these logs by request and timestamp into a central observability system.

How often should I run dormant identity reviews?

I run monthly automated inventories and a quarterly manual review for principals with admin privileges. Shorter cycles catch entitlement creep sooner, but they need automation to scale.

Related Dremio guides

These guides cover adjacent implementation details that are outside this article's main scope.

• Polaris RBAC and credential vending
• how engines use the Polaris REST API
• the related implementation guide
• Troubleshooting Apache Polaris REST API Authentication: 401, 403, Token, and Role Errors
• Upgrading Apache Polaris in Production: Schema Migrations, Rolling Changes, and Rollback

Keep learning

For a deeper treatment, download Apache Polaris: The Definitive Guide, co-authored by Alex Merced and available free from Dremio.

To put the catalog and table-format ideas into practice, explore Dremio Open Catalog.

Sources

• Polaris in-development command line interface documentation, referenced for CLI caveats and potential changes.
• Polaris 1.8.0 access control documentation, used for role, principal, and catalog concepts.
• Polaris 1.8.0 external IDP developer notes, used for guidance on external identity providers and token flows.
• Polaris 1.8.0 download and release page, used to anchor release-specific references.