> For the complete documentation index, see [llms.txt](https://docs.carto.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.carto.com/carto-self-hosted/best-practices/security/security-best-practices.md).

# Security best practices

## Overview

Follow these best practices to harden your CARTO Self-Hosted installation.

## TLS configuration

* Enforce **TLS 1.2 or higher**, and disable TLS 1.0 and 1.1 on your load balancer and ingress controller
* Use **strong cipher suites**
* **Automate certificate renewal** using cert-manager + Let's Encrypt, or your cloud provider's managed certificate service. Do not rely on manual certificate renewal processes

## Secret management

* Rotate secrets regularly — see the [Key rotation schedule](#key-rotation-schedule) section below
* Never commit `carto-secrets.yaml` to version control. Use `.gitignore` and store the file in your secrets manager.

## Network segmentation

* Apply **Kubernetes NetworkPolicies** to restrict pod-to-pod traffic:
  * CARTO pods should only accept traffic from within the CARTO namespace and from the ingress controller
  * PostgreSQL should only accept connections from the CARTO namespace CIDR
  * Valkey should only accept connections from the CARTO namespace
* Use **private cluster networking** — no public node IPs; all inbound traffic through the load balancer only
* If connecting to managed database or cache services, use **private endpoints** (VPC peering, Private Service Connect, PrivateLink, Private Endpoint) to avoid traffic traversing the public internet

## Identity and access

**Use cloud-native workload identity instead of long-lived keys:**

| Cloud | Mechanism         | Benefit                                                            |
| ----- | ----------------- | ------------------------------------------------------------------ |
| GCP   | Workload Identity | CARTO pods authenticate as a GCP service account without key files |
| AWS   | EKS Pod Identity  | CARTO pods assume an IAM role without access keys                  |

See the configuration guides in the [Security configuration section](/carto-self-hosted/configuration/security.md) for setup instructions.

**Restrict Admin Console access (Kots):**

* Change the default Admin Console password immediately after the first login
* Limit network access to the Admin Console port to your operations team's IP range

## Key rotation schedule

| Secret                              | Rotation cadence                                                                          | How to rotate                                                                   |
| ----------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| PostgreSQL database credentials     | Every 90 days                                                                             | Update in your secrets store; restart CARTO pods to pick up the new credentials |
| Object storage service account keys | Every 90 days (if using key-based auth)                                                   | Prefer Workload Identity / IRSA / Managed Identity to eliminate key rotation    |
| TLS certificates                    | Per certificate validity (typically 90 days for Let's Encrypt, 1 year for commercial CAs) | Automate with cert-manager                                                      |
| CARTO license credentials           | On renewal (before expiry)                                                                | Apply updated `carto-secrets.yaml` or Kots license file                         |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.carto.com/carto-self-hosted/best-practices/security/security-best-practices.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.