xCentral Clusters

Explanation (Core Concepts)

What is an xCentral Cluster?

xCentral is the governance hub for your xDP platform. It provides centralized, policy-based access control — powered by Apache Ranger — for every data asset across all compute engines on xDP. Every Spark job, Trino query, and notebook that runs on xDP enforces the access policies you define in xCentral.

xCentral runs entirely inside your own Kubernetes infrastructure. Acceldata manages its lifecycle through the xDP platform, but your governance metadata never leaves your network.

Important: There is a one-per-tenant constraint on xCentral. You can deploy exactly one xCentral cluster per xDP tenant. This cluster should be created and reach a healthy status before you create the xStore (catalog) and xCompute clusters that it governs.

When no xCentral exists for your tenant, the xCentral page shows an empty state with a single call to action — Set up xCentral.

xCentral empty state — no xCentral configured

Key Concepts

Apache Ranger: The policy engine behind xCentral. It stores access policies, synchronizes users and groups, and records audit logs. Linked xStore and xCompute clusters enforce these policies on every query.
PostgreSQL (Internal or External): xCentral requires a PostgreSQL database to store policy definitions, user/group sync records, and audit data. You can deploy one automatically alongside xCentral (internal) or connect to your own managed instance (external). For production, external PostgreSQL with regular backups is strongly recommended.
S3-Compatible Object Storage (Internal or External): xCentral uses object storage for files, assets, and large objects. As with PostgreSQL, you can deploy storage automatically (internal) or connect to an existing S3-compatible service (external).
Connection Type — INTERNAL vs EXTERNAL: Determines how linked compute and catalog clusters reach xCentral. INTERNAL is used when those clusters run on the same Kubernetes cluster and connect over internal service DNS. EXTERNAL is used when they run on a different Kubernetes cluster and must connect through an externally reachable endpoint (configured under Endpoint Configuration in the wizard).

Capabilities

From the xCentral management page you can manage:

Policies — data access policies applied across all linked clusters.
Identity — the users, groups, and roles governed by this xCentral.
Observability (xObserve) — an optional observability stack you can deploy onto xCentral.
Linked clusters — the xStore and xCompute clusters that this xCentral governs.

Tutorial (Getting Started)

Prerequisites

A Kubernetes cluster (version 1.19 or higher) with kubectl configured to reach it.
Cluster-admin privileges on that Kubernetes cluster.
For production: a PostgreSQL database (version 13+) and an S3-compatible object store reachable from Kubernetes. (For a quick start, xCentral can deploy both internally.)
Administrative permissions on the xDP platform.

Step 1 — Prerequisites

Open xCentral from the left sidebar and click Set up xCentral. The 8-step creation wizard opens.
The Prerequisites screen confirms what is needed: Kubernetes v1.19+, cluster-admin access, and kubectl configured to reach your cluster.
Click Next.

Step 1 — Prerequisites

Step 2 — Configure PostgreSQL

Choose your PostgreSQL deployment option:

Internal PostgreSQL (recommended for quick setup and non-production): deployed automatically as part of the installation. No additional configuration is required.
External PostgreSQL (recommended for production): connect to your existing instance by providing the JDBC Database URL (jdbc:postgresql://<host>:5432/xcentral), Username, and Password.

Click Next.

Step 2 — PostgreSQL configuration (Internal selected)

Step 3 — Configure S3-Compatible Object Storage

Choose your object storage deployment option:

Internal S3-Compatible Storage: deployed automatically alongside xCentral, with a default bucket provisioned for you. Ideal for development and testing.
External S3-Compatible Storage: connect to an existing S3-compatible service (including Amazon S3). Provide the Endpoint URL, Access Key, Secret Key, and optionally Bucket Name and Region.

Click Next.

Step 3 — S3-compatible object storage (Internal selected)

Step 4 — xCentral Cluster Details

Fill in the xCentral cluster identity:

XCentral Name: A unique name for this cluster (default: xdp-xcentral).
Namespace: The Kubernetes namespace where xCentral services are deployed (default: xdp-xcentral).
Version: The xCentral release version to deploy. Select from the available versions in the dropdown.
Helm Chart Version: The chart version used to render the deployment (auto-selected).
Description (Optional): A description for this xCentral instance.
Registry Configuration / Endpoint Configuration (optional): expand to configure a private container registry or an external endpoint for EXTERNAL connectivity.

Click Next to create the xCentral record. A confirmation toast — *"XCentral … is being created"* — appears.

Step 4 — xCentral cluster details

Step 5 — Network Settings (Optional)

Configure proxy or host-alias settings if your Kubernetes cluster requires them:

Enable HTTP/HTTPS Proxy: route outbound xCentral traffic through an HTTP proxy server.
Configure Host Aliases: add custom /etc/hosts entries on all cluster nodes — useful for on-premise services that are not in DNS.

Click Next, or Skip This Step if not needed.

Step 5 — Network settings

Step 6 — YAML Configuration

The configuration editor loads with all deployment settings for the xCentral cluster. It supports two modes:

Form mode: a structured editor where boolean values display as toggles.
YAML mode: raw values for full control.

Review the deployment configuration (image repositories, resource limits, PostgreSQL and object-storage settings), then click Save Configuration to continue.

Step 6 — YAML configuration

Step 7 — Install xCentral Cluster

The Install XCentral Cluster screen shows the two commands needed to deploy xCentral onto your Kubernetes cluster:

Download the Kubernetes manifest — run the curl command (or click Download Manifest) to fetch manifest.yaml from xDP.
Apply the manifest to your Kubernetes cluster — run the kubectl command to create the namespace (if needed) and apply the manifest.

Run both commands, tick "I have downloaded the manifest and applied it to my Kubernetes cluster", then click Next.

Step 7 — Install xCentral (credentials masked)

Note: The screenshot above masks the Authorization: Bearer access token for documentation. In the live UI, the command contains your real, short-lived token — treat it as a secret and do not share it.

Step 8 — Setup Complete

The XCentral Registration screen polls for cluster health. It shows Waiting to register XCentral while it checks the installation status — this typically takes a few minutes. Once the cluster is healthy and registers with xDP, click Finish Setup.

Step 8 — Setup complete

You are returned to the xCentral management page, where the new cluster appears with its version, namespace, registry, and an INSTALLING status that transitions to active once registration completes. From here you can manage Policies, Identity, install xObserve, and link xStore / xCompute clusters.

xCentral management page

How-to Guides

Edit an xCentral cluster's configuration

Open xCentral and locate the cluster, then click the Edit icon.
Navigate to the YAML Configuration step.
Update settings in Form or YAML mode (for example, PostgreSQL credentials or resource limits).
Click Save Configuration, then go to the Install step.
Copy and run the updated install commands. The cluster reconciles automatically.

View linked clusters

From the xCentral management page, open the cluster detail view.
Under Linked clusters you can see all xStore and xCompute clusters governed by this xCentral, and add new ones with + Add xStore / + Add xCompute cluster.

Use an external PostgreSQL or object store

In the wizard, select External PostgreSQL (Step 2) and/or External S3-Compatible Storage (Step 3).
Provide the connection details (URL/endpoint, credentials, and — for storage — bucket and region).
Continue through the wizard as normal. The external services are referenced in the generated deployment manifest.

Configure a proxy or host aliases

In the wizard, reach Network Settings (Step 5).
Toggle Enable HTTP/HTTPS Proxy to route outbound traffic through a proxy, and/or Configure Host Aliases to add /etc/hosts entries for on-premise hostnames.

Delete an xCentral cluster

From the xCentral management page, open the cluster's actions menu and click Delete.
Confirm the deletion. xDP removes the cluster from its registry.

Warning: Before deleting xCentral, unlink all xStore and xCompute clusters from it. Deleting xCentral while clusters are linked leaves those clusters without governance enforcement. The underlying cluster resources are not automatically removed — clean up the xCentral namespace afterward.

Reference

Creation wizard steps

Step	Name	Required	What it configures
1	Prerequisites	—	Informational: Kubernetes v1.19+, cluster-admin, `kubectl`.
2	PostgreSQL	Yes	Internal (auto-deployed) or external PostgreSQL connection.
3	S3-Compatible Storage	Yes	Internal (auto-deployed) or external object storage.
4	XCentral Details	Yes	Name, namespace, version, helm chart version, description, registry, endpoint.
5	Network Settings	Optional	HTTP/HTTPS proxy and host aliases.
6	YAML Configuration	Yes	Review/edit the rendered deployment config (Form or YAML mode).
7	Install XCentral	Yes	Download + apply the Kubernetes manifest via `curl` and `kubectl`.
8	Setup Complete	—	Polls for registration; Finish Setup when healthy.

Cluster details fields

Field	Default	Description
XCentral Name	`xdp-xcentral`	Unique name for the cluster.
Namespace	`xdp-xcentral`	Kubernetes namespace for xCentral services.
Version	latest available	xCentral release to deploy.
Helm Chart Version	auto-selected	Chart version used to render the deployment.
Description	—	Optional free-text description.
Registry Configuration	platform default	Optional private container registry.
Endpoint Configuration	—	Optional external endpoint (for EXTERNAL connection type).

Connection type

Type	Use when	How clusters connect
INTERNAL	Linked clusters run on the same Kubernetes cluster	Internal service DNS
EXTERNAL	Linked clusters run on a different Kubernetes cluster	Externally reachable endpoint URL (with mTLS)

Best Practices

Tip: Create xCentral first, get it healthy, then build the rest of your platform on top of it.

Create xCentral before xStore and xCompute. xCentral is the governance prerequisite for all other xDP clusters — establish it first so policies are in place from the start.
Use external PostgreSQL for production. A dedicated external instance simplifies backup, recovery, and sizing, and keeps governance performance consistent.
Test policies before production. Verify access policies are enforced correctly with test queries from non-privileged users before directing production workloads.
Keep xCentral updated. Policy-engine updates often include security improvements and new catalog-provider support.
Use host aliases for on-premise DNS. If your cluster cannot resolve on-premise hostnames (e.g., for external PostgreSQL or object storage), add host aliases in Network Settings.
Protect the install token. The Authorization: Bearer token in the install command is a short-lived secret — never paste it into tickets, chats, or screenshots.

Last updated on

Was this page helpful?