Skip to main content

StrongDM Guide: Zero-Trust Access to Everything

1. Introduction: The End of Static Credentials​

In a modern, dynamic cloud environment, the concept of a "trusted internal network" is obsolete. We operate on a Zero-Trust security model, which assumes that no user or system, whether internal or external, should be trusted by default. Access to every resource must be explicitly granted, authenticated, and logged.

StrongDM is the core of our Zero-Trust strategy for infrastructure access. It is the single, unified gateway through which all engineers access our most sensitive resources, including databases, Kubernetes clusters, and SSH servers. It eliminates the need for engineers to ever possess static credentials like database passwords or SSH keys.

Core Mission: To provide engineers with temporary, just-in-time, and fully-auditable access to the resources they need, without ever exposing long-lived credentials.

2. Why We Use StrongDM: The Problems it Solves​

  • No More Shared Secrets: We never have to share a prod-db.pem key or a master database password again. StrongDM manages all the underlying credentials.
  • Centralized, Auditable Logs: Every query, every SSH session, and every Kubernetes command executed through StrongDM is logged in a centralized, tamper-proof audit trail. This is essential for security analysis and compliance.
  • Role-Based Access Control (RBAC): We define roles (e.g., k8s-prod-readonly, db-customers-dev-write) and grant access to those roles, not to individual resources. This makes access management scalable and easy to reason about.
  • Temporary, Just-in-Time Access: A developer should not have standing access to the production database. With StrongDM, they can request temporary access to a specific resource for a limited time (e.g., "I need 1 hour of access to the prod-replica database to debug a query").

3. The Access Workflow: Requesting What You Need, When You Need It​

Our access workflow is designed to be self-service and fast, with clear approval gates.

  1. Request Access: An engineer needs to debug an issue on a production Kubernetes pod. They go to the StrongDM UI or use the sdm CLI.
  2. Select Resource & Time: They select the production-k8s cluster and request kubectl exec permissions for a duration of 2 hours.
  3. Approval:
    • Because kubectl exec in production is a sensitive permission, this request requires approval.
    • The engineer's manager receives a Slack notification from StrongDM with "Approve" and "Deny" buttons.
    • The manager reviews the justification ("Debugging P2 incident JIRA-123") and approves the request.
  4. Access Granted: The engineer immediately has the permissions they need. When they run kubectl exec, StrongDM authenticates them, checks their permissions, and proxies the connection to the Kubernetes API server.
  5. Auto-Revocation: After 2 hours, the engineer's access to kubectl exec is automatically and silently revoked.
  6. Audit Trail: The entire session—the request, the approval, and every command the engineer ran inside the pod—is recorded in the StrongDM audit log.

4. Configuration as Code: Managing StrongDM with Terraform​

All StrongDM resources—roles, datasources, clusters, and the connections between them—are managed as code using Terraform. This ensures our access policies are version-controlled and auditable. The configuration is stored in the infra-observability repository.

Example: Defining a Read-Only Database Role​

This Terraform code defines a new PostgreSQL database and creates a read-only role for it.

# 1. Define the datasource (the database itself)
resource "sdm_resource" "prod_replica_db" {
  postgres {
    name                = "production-replica-db"
    hostname            = "replica.prod.us-east-1.rds.amazonaws.com"
    port                = 5432
    username            = var.db_readonly_user
    password            = var.db_readonly_password
    database            = "main"
    port_override       = 15432
    tls_required        = true
  }
}

# 2. Define the role that can access the datasource
resource "sdm_role" "db_prod_readonly" {
  name = "db-prod-readonly"
}

# 3. Create the grant that connects the role to the datasource
resource "sdm_account_attachment" "db_prod_readonly_attachment" {
  account_id = sdm_role.db_prod_readonly.id
  resource_id = sdm_resource.prod_replica_db.id
}

When an engineer requests access, they are requesting to be temporarily added to the db-prod-readonly role. The sdm_account_attachment is what makes the connection. When a new database is provisioned, adding it to StrongDM is as simple as creating a new sdm_resource block and opening a Pull Request.

5. Sparky's Role in StrongDM Management​

  • Automated Deprovisioning: As detailed in the Platform Operations guide, Sparky plays a key role in our quarterly access control audits. When the audit script identifies an employee who has left the company, Sparky automatically uses the StrongDM API to suspend their account, ensuring off-boarding is swift and complete.
  • Emergency Access Grants: In a P1 incident, the Incident Commander can invoke a Sparky command: @Sparky grant @JohnDoe role db-prod-admin for 1 hour reason "P1 Incident JIRA-456". Sparky, which has its own highly-restricted role in StrongDM, can execute this emergency grant, logging the IC's command and the Jira ticket as the justification. This is faster than the manual approval flow and just as auditable.