Replacing SSH Keys with Teleport: A Zero Trust Migration Guide

Your team has 47 SSH keys scattered across jump boxes, and nobody remembers who owns the one labeled prod-deploy-old. Last week’s security audit flagged three accounts for engineers who left six months ago. The private key for your CI/CD pipeline lives in a shared S3 bucket because “that’s how it was set up in 2019.” Traditional SSH key management doesn’t scale, and you know it.

The uncomfortable truth is that SSH keys are static credentials masquerading as security. They have no expiration by default, no centralized revocation, and no audit trail beyond grep-ing through authorized_keys files across dozens of servers. Every key you’ve ever generated still works somewhere, and you’ve lost track of where.

This isn’t a tooling problem—it’s an architectural one. SSH was designed for a world where servers were pets with names, not cattle with tags. The protocol assumes you know every machine you’ll ever connect to and can manually distribute keys to each one. That assumption broke the moment your infrastructure grew beyond a single rack.

Zero trust security demands that every access request be authenticated, authorized, and encrypted—regardless of network location. Static SSH keys fail all three requirements. They authenticate a key, not a person. They authorize based on file permissions, not policy. And once compromised, they provide persistent access until someone remembers to rotate them.

Teleport offers a different model: short-lived certificates tied to identity providers, with every session logged, recorded, and auditable. The migration isn’t trivial, but it’s more straightforward than maintaining the status quo. Here’s how to make it happen.

The SSH Key Management Problem Nobody Wants to Admit

Every infrastructure team has a dirty secret: a ~/.ssh directory that tells a story of accumulated access, forgotten permissions, and security practices that would make any auditor wince. SSH keys are the cockroaches of infrastructure security—easy to create, nearly impossible to eliminate, and somehow always surviving longer than the systems they were meant to protect.

The Accumulation Problem

SSH keys follow a predictable lifecycle. A developer needs access to a production server for a hotfix at 2 AM. A key gets generated, distributed, and added to authorized_keys. The fix ships. The key remains. Multiply this by every engineer, contractor, and automated system across a five-year infrastructure evolution, and you’re left with a cryptographic archaeology project.

The math is brutal: a team of 15 engineers accessing 50 servers generates 750 potential key-to-host relationships. Factor in service accounts, CI/CD pipelines, and that consultant from 2022 who “definitely” returned all their credentials, and auditing becomes a forensic investigation rather than a routine check.

Static Credentials in a Zero Trust World

Zero trust architecture operates on a fundamental principle: never trust, always verify. Static SSH keys violate this principle by design. A key generated today grants the same access in six months, regardless of whether the engineer still works at the company, the server’s role has changed, or the threat landscape has evolved.

Traditional SSH authentication answers one question: “Does this private key match a public key on this server?” It cannot answer the questions that matter: “Should this person have access right now? From this location? For this purpose?”

The Hidden Operational Tax

The true cost of SSH key management hides in operational overhead that teams rarely quantify:

Offboarding becomes a treasure hunt. When an engineer leaves, someone must trace every server they ever accessed and manually remove their public keys. Miss one, and you’ve created a persistent backdoor.

Key rotation requires synchronized chaos. Rotating keys across a fleet means coordinating updates to every server, every deployment script, and every developer workstation simultaneously—or accepting downtime.

Compliance audits trigger existential dread. Proving who had access to what systems and when becomes an exercise in reconstructing history from incomplete logs and tribal knowledge.

Why Bastion Hosts Fall Short

Jump boxes and bastion hosts address symptoms, not causes. They centralize the entry point while leaving the underlying key management chaos intact. You’ve added a chokepoint to your architecture without solving the fundamental identity problem. Engineers still manage static keys; they just route them through an additional hop.

The infrastructure access problem demands a different approach—one where identity, not keys, becomes the foundation of trust. Short-lived certificates, tied to verified identities and scoped to specific resources, offer that foundation.

How Teleport Reimagines Infrastructure Identity

The fundamental problem with SSH keys isn’t that they’re insecure—it’s that they’re static. A key generated today remains valid until someone remembers to revoke it, which statistically means it remains valid forever. Teleport inverts this model entirely by treating infrastructure access as an identity problem rather than a key distribution problem.

Certificates Replace Keys

Traditional SSH authentication asks: “Do you possess the correct private key?” Teleport authentication asks: “Who are you, and what should you be allowed to do right now?”

This shift from possession-based to identity-based authentication changes everything. When you authenticate to Teleport, you receive a short-lived X.509 certificate that encodes your identity, your roles, and an expiration timestamp. The certificate is cryptographically signed by Teleport’s Certificate Authority, which means any server in your infrastructure can verify your identity without maintaining its own list of authorized keys.

The practical difference: instead of distributing public keys to every server and hoping your revocation process works, you distribute trust in a single Certificate Authority. Servers don’t need to know about individual users—they need to trust the CA that vouches for them.

Short-Lived Credentials by Default

Teleport certificates expire. The default lifetime is 12 hours, though this is configurable based on your security requirements. When the certificate expires, access stops. No revocation lists to maintain, no key rotation schedules to forget, no “temporary” access that becomes permanent through organizational inertia.

This automatic expiration eliminates an entire category of security debt. That contractor who left six months ago? Their certificate expired on day one. The engineer who rotated to a different team? Their access ended when their session did. The laptop that got stolen? The attacker has hours, not months, to exploit any extracted credentials.

SSO as the Source of Truth

Teleport delegates identity verification to your existing SSO provider—Okta, Azure AD, Google Workspace, or any SAML/OIDC-compliant system. When an engineer authenticates, Teleport queries your identity provider, pulls group memberships, and maps those to infrastructure roles.

This integration means infrastructure access inherits your existing identity lifecycle. Disable a user in your IdP, and their Teleport access ends immediately. Update group memberships, and permissions adjust at next authentication. Your SSO becomes the single source of truth for who can access what.

The Three-Component Architecture

Teleport’s architecture separates concerns across three components:

The Auth Service acts as the Certificate Authority and the brain of your cluster. It authenticates users, issues certificates, and enforces access policies. In production, you run this highly available.

The Proxy Service handles all incoming connections and routes them to the appropriate destination. Users connect here—never directly to protected resources. This creates a single ingress point for auditing and access control.

Agents run on your servers, Kubernetes clusters, and databases. They maintain a reverse tunnel to the Proxy Service, which means protected resources don’t need inbound firewall rules. The agent handles certificate verification and enforces the access policies the Auth Service defines.

This architecture means your servers become unreachable except through Teleport. No exposed SSH ports, no key-based backdoors, no “just this once” exceptions that become permanent fixtures.

With the security model understood, the next step is standing up your first cluster and seeing this architecture in practice.

Setting Up Your First Teleport Cluster

With the conceptual foundation in place, let’s deploy a production-ready Teleport cluster. This walkthrough covers deploying the core services, configuring them for your environment, and enrolling your first server node. By the end, you’ll have a working cluster with certificate-based authentication replacing traditional SSH keys.

Deploying Auth and Proxy Services

Teleport’s architecture separates concerns into distinct services. The Auth Service manages certificates, stores cluster state, and handles authentication. It acts as the cluster’s certificate authority, issuing short-lived credentials to users and machines. The Proxy Service terminates user connections and routes traffic to backend resources, serving as the single point of entry for all client connections. For smaller deployments, both services run on a single host; larger environments typically distribute them across dedicated infrastructure for high availability.

Start by installing Teleport on your designated cluster host. On Ubuntu/Debian systems:

curl https://goteleport.com/static/install.sh | bash -s 16.0.0

For RHEL/CentOS systems, use the RPM repository instead. Verify the installation completed successfully by running teleport version to confirm the binary is accessible.

Create your cluster configuration file. This example configures both services with filesystem-based storage suitable for single-node deployments:

version: v3
teleport:
  nodename: teleport.example.com
  data_dir: /var/lib/teleport
  log:
    output: stderr
    severity: INFO

auth_service:
  enabled: true
  cluster_name: production-cluster
  listen_addr: 0.0.0.0:3025
  tokens:
    - proxy,node:secure-join-token-change-me-abc123

proxy_service:
  enabled: true
  web_listen_addr: 0.0.0.0:443
  public_addr: teleport.example.com:443
  https_keypairs:
    - key_file: /etc/teleport/certs/server.key
      cert_file: /etc/teleport/certs/server.crt

ssh_service:
  enabled: false

The cluster_name uniquely identifies your Teleport cluster and appears in audit logs and certificate metadata. Choose a descriptive name that reflects your environment. The public_addr must resolve to your Proxy Service and match the certificate’s Common Name or Subject Alternative Names.

💡 Pro Tip: For production deployments, use a static join token only during initial setup. Switch to short-lived tokens generated via tctl tokens add once your cluster is operational. This limits the exposure window if a token is compromised.

Start the service and enable it for automatic startup:

sudo systemctl enable teleport
sudo systemctl start teleport

Verify the Auth Service is running by checking the cluster status:

sudo tctl status

You should see output confirming your cluster name, version, and CA pin. The CA pin is a cryptographic fingerprint you’ll use to verify cluster identity when joining nodes.

Registering Your First Node

With the control plane running, enroll a server into your cluster. On the target node, install Teleport using the same installation script, then create a minimal configuration:

version: v3
teleport:
  nodename: webserver-01
  data_dir: /var/lib/teleport
  auth_token: secure-join-token-change-me-abc123
  proxy_server: teleport.example.com:443

ssh_service:
  enabled: true
  labels:
    env: production
    role: webserver

auth_service:
  enabled: false

proxy_service:
  enabled: false

The auth_token field references the static token defined in your Auth Service configuration. The proxy_server directive tells this node where to establish its connection—all communication flows through the Proxy Service. The labels block attaches metadata used for RBAC policies. Design your labeling taxonomy early; consistent tagging enables powerful access controls like “grant SREs access to all nodes labeled env: production.”

Start the Teleport service on this node:

sudo systemctl enable teleport
sudo systemctl start teleport

Back on your cluster host, confirm the node registered successfully:

sudo tctl nodes ls

The output displays the node’s hostname, address, labels, and the version of Teleport it’s running. If the node doesn’t appear, check the node’s logs with journalctl -u teleport for connection errors.

Verifying Access with tsh

The tsh command-line tool is your primary interface for accessing Teleport-protected resources. On your workstation, install tsh and authenticate against the cluster:

tsh login --proxy=teleport.example.com --user=admin

This opens a browser window for authentication (or prompts for credentials if using local auth). Upon success, Teleport issues a short-lived certificate stored in ~/.tsh. These certificates typically expire within hours, not months—dramatically reducing the risk of credential theft.

List available nodes:

tsh ls

Connect to your registered server:

tsh ssh root@webserver-01

Notice you’re connecting by node name, not IP address. Teleport handles service discovery and certificate validation transparently. Your connection is authenticated, encrypted, and fully audited in the cluster’s session recordings.

💡 Pro Tip: Run tsh status to inspect your current certificate, including its expiration time and the roles it carries. This becomes invaluable when debugging access issues or understanding why a particular resource is inaccessible.

At this point, you have a functional Teleport cluster with one enrolled node. The certificate-based authentication is already replacing SSH keys—but we’re authenticating against Teleport’s local user database. The real power emerges when we integrate your existing identity provider for single sign-on and implement role-based access controls to enforce least-privilege access across your infrastructure.

Integrating SSO and Implementing RBAC

Manual user provisioning is a scaling bottleneck that creates security gaps. Every time someone joins, leaves, or changes teams, you’re updating access controls by hand—and hoping you didn’t miss anything. Teleport eliminates this overhead by delegating authentication to your existing identity provider and automatically mapping group memberships to fine-grained roles.

Connecting Your Identity Provider

Teleport supports both OIDC and SAML 2.0, making it compatible with Okta, Azure AD, Google Workspace, and most enterprise identity platforms. The configuration lives in a connector resource that defines how Teleport communicates with your IdP and translates identity claims into role assignments.

Here’s an OIDC connector for Okta:

kind: oidc
version: v3
metadata:
  name: okta
spec:
  issuer_url: https://acme-corp.okta.com
  client_id: 0oa8k2j4n5m6l7p8q9r0
  client_secret: your-client-secret-from-okta
  redirect_url: https://teleport.acme-corp.com:443/v1/webapi/oidc/callback
  claims_to_roles:
    - claim: groups
      value: platform-engineers
      roles:
        - platform-admin
    - claim: groups
      value: developers
      roles:
        - developer
    - claim: groups
      value: contractors
      roles:
        - contractor-readonly

Apply the connector with tctl create -f okta-connector.yaml. Users authenticating through Okta now receive Teleport roles based on their group memberships—no manual mapping required. The claims_to_roles section is where the automation happens: each mapping evaluates the user’s identity claims at login time and assigns the corresponding roles dynamically.

For organizations using SAML, the connector structure is similar but references SAML assertions instead of OIDC claims. Teleport normalizes both protocols into the same internal role-mapping mechanism, so your access policies remain consistent regardless of which identity protocol your IdP supports.

Defining Granular Roles

Teleport roles control what users can access and what they can do once connected. The power lies in combining node labels, login permissions, and session controls into precise access policies that adapt to your organizational structure.

kind: role
version: v7
metadata:
  name: developer
spec:
  allow:
    logins:
      - "{{internal.logins}}"
      - ubuntu
    node_labels:
      environment: ["development", "staging"]
      team: "{{external.team}}"
    rules:
      - resources: [session]
        verbs: [list, read]
  deny:
    node_labels:
      environment: production
  options:
    max_session_ttl: 8h
    forward_agent: false

This role grants developers access to development and staging nodes matching their team label, explicitly denies production access, and caps sessions at eight hours. The {{external.team}} syntax pulls the team claim from your IdP, enabling dynamic access based on identity attributes. This template syntax means you define the role once, and it automatically scopes access correctly for every team in your organization.

The deny block takes precedence over allow, providing a fail-safe mechanism for protecting sensitive resources. Even if a misconfiguration grants broader access than intended, explicit deny rules ensure critical boundaries remain enforced.

💡 Pro Tip: Start with restrictive deny rules and expand access incrementally. It’s easier to grant additional permissions than to revoke access after an incident.

Just-in-Time Access Requests

Permanent elevated access violates least-privilege principles. Teleport’s access request workflow lets users request temporary permissions with full audit trails and approval chains, ensuring that sensitive access is always time-bounded and justified.

kind: role
version: v7
metadata:
  name: production-access
spec:
  allow:
    request:
      roles:
        - production-admin
      thresholds:
        - approve: 2
          deny: 1
      max_duration: 4h
    logins:
      - ubuntu
    node_labels:
      environment: production

When a developer needs production access for an incident, they run tsh request create --roles=production-admin --reason="Investigating memory leak in order service". Two approvers must sign off before access is granted, and the elevated permissions automatically expire after four hours. Every request, approval, and denial is logged with full context, creating an audit trail that satisfies compliance requirements.

The approval workflow integrates with Slack, PagerDuty, and other tools through Teleport’s plugin system. Approvers receive notifications with the request context and can approve directly from their preferred interface, reducing friction while maintaining security controls.

Automating Role Lifecycle

Group membership changes in your IdP propagate automatically on the next authentication. When someone moves from engineering to management, their Teleport roles update without any infrastructure team involvement. When someone leaves the company, IdP deprovisioning immediately revokes all infrastructure access—no stale credentials lingering in your infrastructure.

This tight coupling between identity and access transforms user lifecycle management from a recurring task into a solved problem. Your security posture improves because access rights always reflect current organizational reality rather than outdated manual configurations.

With authentication centralized and roles defined, you’re ready to bring your existing servers into the cluster without disrupting active sessions or established workflows.

Migrating Existing Infrastructure Without Downtime

The worst migration strategy is the big-bang cutover. One Friday afternoon, you disable all SSH keys, flip the switch to Teleport, and pray nothing breaks. Spoiler: something always breaks. A forgotten cron job, an ancient backup script, that one engineer who never reads the migration emails.

A zero-downtime migration runs Teleport alongside your existing SSH access, gradually shifting traffic until you can safely retire legacy keys with full visibility into what’s still using them.

Running Parallel Access

Install the Teleport agent on your servers without touching existing SSH configurations. The agent listens on a separate port and registers with your cluster while OpenSSH continues operating normally.

## Download and install the Teleport agent
curl -O https://cdn.teleport.dev/teleport-v15.1.0-linux-amd64-bin.tar.gz
tar -xzf teleport-v15.1.0-linux-amd64-bin.tar.gz
sudo ./teleport/install

## Generate a join token from your Teleport cluster
## Run this on your Teleport auth server
tctl tokens add --type=node --ttl=1h

## Configure the agent on your target server
sudo teleport configure \
  --roles=node \
  --token=a]s#d8f7g6h5j4k3l2m1n0p9q8r7s6t5 \
  --auth-server=teleport.yourcompany.com:443 \
  --node-name=$(hostname) \
  --output=/etc/teleport.yaml

## Start the agent
sudo systemctl enable teleport
sudo systemctl start teleport

Your server now accepts connections through both traditional SSH (port 22) and Teleport. Engineers can continue using their existing workflows while you validate the new access path.

Staged Rollout Strategy

Start with development environments where the blast radius of misconfiguration is minimal. Deploy agents to dev servers, have your team use tsh ssh for a week, and collect feedback. Common issues surface quickly: missing role mappings, unexpected session recording behavior, or SSO integration quirks.

Move to staging only after dev runs clean for at least one sprint. Production comes last, and you deploy in waves—start with non-critical services, then stateless application servers, and finally databases and core infrastructure.

Updating Automation

CI/CD pipelines and automated scripts need explicit attention. Replace direct SSH calls with tsh using machine credentials.

#!/bin/bash
## Old approach - static SSH key
## ssh -i /path/to/deploy_key deploy@app-server-01 "cd /app && git pull && restart"

## New approach - Teleport machine identity
export TELEPORT_AUTH_SERVER=teleport.yourcompany.com:443
export TELEPORT_IDENTITY_FILE=/etc/teleport/machine-id/identity

tsh ssh deploy@app-server-01 "cd /app && git pull && systemctl restart app"

For CI systems like GitHub Actions or GitLab CI, use Teleport’s Machine ID to issue short-lived certificates to your runners. Each pipeline run gets unique credentials that expire within minutes, eliminating the persistent deploy key antipattern.

Deprecating Legacy Keys Safely

Before removing any SSH key, audit its usage. Teleport’s session recordings and access logs reveal which keys are still active, but you also need visibility into direct SSH connections.

## Find all authorized_keys entries across your fleet
tsh ssh root@"*" "cat ~/.ssh/authorized_keys 2>/dev/null" > all_authorized_keys.txt

## Check SSH auth logs for recent key usage
tsh ssh root@app-server-01 "grep 'Accepted publickey' /var/log/auth.log | tail -50"

Set a deprecation timeline: announce the cutoff date, disable keys in staging first, monitor for access failures, then proceed to production. Keep emergency break-glass keys in a hardware security module for disaster recovery, but require dual approval to access them.

Once your audit confirms zero legacy key usage for 30 days, you can confidently disable port 22 and remove authorized_keys files. Your infrastructure now runs entirely on cryptographic identity.

Teleport’s value extends beyond SSH. The same identity framework that secures your servers also handles Kubernetes clusters and database connections—a unified access layer we’ll explore next.

Beyond SSH: Extending to Kubernetes and Databases

Once your SSH access runs through Teleport, extending that same identity to Kubernetes clusters and databases becomes straightforward. The authentication model stays identical—your SSO credentials generate short-lived certificates—while Teleport handles the protocol-specific details. This unified approach eliminates the credential sprawl that plagues traditional infrastructure access patterns.

Kubernetes Access Through the Same Identity

Adding a Kubernetes cluster requires deploying the Teleport agent with cluster access enabled. Create a configuration that connects your cluster to the Teleport proxy:

teleport:
  auth_token: "/var/lib/teleport/token"
  proxy_server: "teleport.timderzhavets.com:443"

kubernetes_service:
  enabled: true
  listen_addr: 0.0.0.0:3027
  kube_cluster_name: "production-us-east"
  labels:
    env: production
    region: us-east-1

After deploying the agent, your engineers authenticate once and access both SSH and Kubernetes resources:

tsh login --proxy=teleport.timderzhavets.com
tsh kube login production-us-east
kubectl get pods -n application

The RBAC configuration from the previous section extends directly. Engineers with the kubernetes_labels selector matching env: production gain cluster access automatically—no separate kubeconfig files to distribute or rotate. This eliminates the common pattern of engineers accumulating stale kubeconfig entries for clusters they no longer need access to, reducing both security exposure and operational confusion.

Database Connections with Short-Lived Credentials

Traditional database access requires distributing connection strings with embedded credentials. These credentials inevitably end up in configuration files, environment variables, and password managers—each copy representing a potential breach vector. Teleport replaces this pattern with certificate-based authentication that respects your existing role definitions.

Register a PostgreSQL database by adding it to your Teleport configuration:

db_service:
  enabled: true
  databases:
    - name: "orders-primary"
      protocol: "postgres"
      uri: "orders-db.internal.timderzhavets.com:5432"
      static_labels:
        env: production
        team: platform

Engineers connect through the Teleport proxy, receiving credentials valid for the duration of their session:

tsh db login orders-primary --db-user=app_readonly
tsh db connect orders-primary

💡 Pro Tip: Configure database users in PostgreSQL to authenticate via certificate CN matching. This eliminates password-based access entirely while maintaining granular permission control at the database level.

The same approach works for MySQL, MongoDB, Redis, and other supported database protocols. Each connection generates a fresh certificate, and when the session ends, those credentials become invalid immediately—not after a password rotation cycle that might be weeks away.

Unified Audit Trail

Every SSH session, Kubernetes API call, and database query flows through the same audit system. A single query surfaces all infrastructure access for a given user or time window:

tctl recordings ls --from=2024-01-15 --user=deploy-bot

This unified logging transforms compliance from a quarterly scramble into a standard operational query. Security teams gain visibility across infrastructure boundaries without aggregating logs from disparate systems. When an incident occurs, investigators can trace a user’s complete infrastructure footprint without correlating timestamps across multiple logging backends.

The Path Forward

Teleport’s privileged access management capabilities extend beyond what we’ve covered—application access proxying, machine-to-machine identity, and desktop access all build on the same certificate authority. Each addition strengthens the security model without introducing new credential management overhead. Organizations typically start with SSH, expand to Kubernetes and databases as confidence grows, then evaluate application-layer proxying for internal tools.

With your infrastructure access consolidated under cryptographic identity, operational patterns shift. The next section examines the practical lessons from running Teleport in production: monitoring strategies, upgrade considerations, and the organizational changes that accompany zero trust adoption.

Operational Considerations and Lessons Learned

Running Teleport in production requires planning beyond the initial deployment. After migrating dozens of teams from traditional SSH keys, clear patterns emerge around what separates smooth operations from painful firefighting.

High Availability Architecture

A single Teleport Auth Service becomes a critical dependency for all infrastructure access. Deploy a minimum of three Auth Service instances behind a load balancer, backed by a highly available datastore like etcd or DynamoDB. The Proxy Service scales horizontally without coordination—add instances behind your load balancer as connection counts grow.

Geographic distribution matters for global teams. Deploy Proxy Services in each region where your engineers work to minimize latency on interactive sessions. The Auth Service can remain centralized, but consider read replicas for token validation if you operate across continents.

Monitoring Access Events

Teleport’s audit log captures every session, command, and access attempt. Stream these events to your SIEM and build alerts for anomalies: failed authentication spikes, access to production nodes outside business hours, or sessions from unusual geographic locations.

💡 Pro Tip: Create dashboards showing certificate issuance rates and session durations. A sudden drop in certificate requests often indicates SSO integration issues before users start filing tickets.

Monitor certificate expiration across your fleet. Nodes with expired host certificates silently drop out of the cluster, creating confusing “host not found” errors during incident response—exactly when you need access most.

Common Pitfalls

Overly broad roles during migration. Teams often create permissive roles to avoid blocking access, then never tighten them. Start restrictive and grant exceptions through proper requests.

Neglecting the Auth Service backup. Losing your Auth Service data means regenerating every certificate authority and re-enrolling every node. Automate encrypted backups and test restores quarterly.

Forgetting about service accounts. Automated systems using SSH keys need migration too. Plan for machine identity certificates early, not as an afterthought when CI/CD pipelines break.

When Teleport Might Not Fit

Small teams with fewer than ten servers and stable access patterns gain marginal benefit over simple authorized_keys management. Highly regulated environments requiring air-gapped infrastructure may find the connectivity requirements problematic. Organizations deeply invested in competing solutions like HashiCorp Boundary should evaluate migration costs honestly.

With operational foundations in place, Teleport transforms infrastructure access from a security liability into an auditable, identity-driven system that scales with your organization.

Key Takeaways

• Start your migration with a parallel deployment - run Teleport agents alongside existing SSH access to minimize risk and build team confidence
• Integrate with your existing SSO provider immediately to eliminate manual user provisioning and automatically revoke access when employees leave
• Use node labels and RBAC roles to implement least-privilege access from day one, not as a future improvement
• Extend beyond SSH to Kubernetes and databases once server access is stable - the same identity model applies across all infrastructure