> 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

Security recommendations for CARTO Self-Hosted

## 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.