Teleport Self-hosted
You set up a teleport self hosted cluster by running an auth server and node agents. These parts issue short-lived certificates so engineers can log in to servers, databases, and Kubernetes clusters. Teams often run this setup on their own cloud servers to keep full control over keys. Still, broad roles can still give users too much power once they log in. How a teleport self hosted setup works A self-managed deployment relies on three main software roles that run on your own servers. The aut
Teleport + Self-Service Access Portals: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a teleport self hosted cluster by running an auth server and node agents. These parts issue short-lived certificates so engineers can log in to servers, databases, and Kubernetes clusters. Teams often run this setup on their own cloud servers to keep full control over keys. Still, broad roles can still give users too much power once they log in.
How a teleport self hosted setup works
A self-managed deployment relies on three main software roles that run on your own servers. The auth service acts as the central certificate authority for your whole team. It checks user identities against your single sign-on tool and issues short-lived certificates. It also stores audit logs and cluster state in a backend storage system.
The second part presents the public login entry point for your users and tools. It accepts incoming requests from engineers and forwards them to the right internal nodes. The third part is the resource agent, which runs near your servers or databases. Agents dial back to the main cluster so you do not open inbound firewall ports.
When an engineer wants to work, they log in through their command line tool. The auth service checks their group membership and maps it to a specific cluster role. That role lists which labels the user can see and which system logins they can use. The user then gets a temporary certificate that expires after a few hours.
Day-two operations for self-managed clusters
Running the control plane yourself means your team owns high availability and storage backups. If the auth service goes down, nobody can get new certificates to reach production systems. Teams usually spread multiple auth and entry servers across different cloud zones for safety. You must also manage TLS certificates for the public endpoints and rotate host keys.
Upgrades require careful planning across all your servers and agents. You must update the central auth servers before you update the downstream node agents. If version numbers drift too far apart, agents might fail to talk to the control plane. Your team also needs to ship the audit logs to an external storage bucket for safety.
Teleport + Self-Service Access Portals: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What host and role controls leave open
This certificate model solves the big problem of static SSH keys and shared database passwords. It gives you a clear check on who can open a session to a given host. You can also require peer reviews before someone assumes a high-privilege role for an hour.
Still, entry checks only decide who can start a session on a target machine. Once the session starts, the user holds the full power of that database role or Linux account. A broad database role lets an engineer run a destructive delete query by mistake. A shared admin account on a server lets someone read raw customer emails or card numbers. Certificate checks at the door cannot inspect or filter individual commands and queries in flight. They also do not rewrite sensitive fields like phone numbers or national IDs inside query results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What components do I need to run a self-managed cluster?
You need an auth service, a public entry service, and agents on your target resources. For production, you also need shared backend storage for state and audit logs.
How do agents talk to the main cluster without inbound ports?
Resource agents open an outbound tunnel back to the main entry service on startup. Traffic then flows through that reverse tunnel, so your private networks stay closed to outside scans.
Why are role checks not enough for database safety?
A role check only controls who can log in to a specific database instance. Once inside, the user can still run risky queries or pull unmasked emails and card numbers.