Terraform Associate

Deep Dive

Practicar ahora
D7 · Implementación y mantenimiento

HCP Terraform: workspaces, VCS y governance

HCP Terraform (antes Terraform Cloud) es la plataforma SaaS de HashiCorp para equipos. Entender su modelo de organizaciones/workspaces, la integración con VCS, la ejecución remota y las políticas Sentinel es fundamental para el examen.

HCP Terraform overview

HCP Terraform (HashiCorp Cloud Platform Terraform, antes Terraform Cloud) es el servicio SaaS de HashiCorp que añade colaboración, governance y automatización sobre Terraform CLI.

URL: app.terraform.io. Acceso con terraform login.

Estado remoto

El estado se almacena en HCP con cifrado, versionado y locking automático.

Ejecución remota

Los planes y applies se ejecutan en agentes HCP, no en tu máquina local.

Integración VCS

Conecta con GitHub/GitLab. Los PRs disparan plans especulativos automáticamente.

Governance

Políticas Sentinel y OPA para validar cambios antes del apply.

Variable sets

Conjuntos de variables reutilizables en múltiples workspaces.

Registry privado

Publica módulos internos accesibles desde todos los workspaces de la organización.

Organizaciones y workspaces

En HCP Terraform, las organizaciones son el contenedor de nivel superior. Los workspaces son entornos de trabajo aislados dentro de una organización.

ConceptoDescripción
OrganizaciónContenedor raíz en HCP. Puede tener múltiples equipos (teams), workspaces y members. Tiene su propio plan de suscripción.
WorkspaceUnidad de trabajo. Tiene: estado propio, variables propias, configuración VCS, historial de runs y permisos de acceso.
RunEjecución de un plan o apply. Queda registrado con su output, quién lo ejecutó y cuándo.
TeamGrupo de usuarios con permisos específicos sobre workspaces. Disponible en Plus y Enterprise.
Variable de workspaceVariable Terraform o variable de entorno configurada directamente en el workspace (sobrescribe tfvars).

💡 Workspace HCP ≠ workspace CLI

Los workspaces de CLI (terraform workspace new) son simplemente múltiples estados en el mismo directorio. Los workspaces de HCP Terraform son entornos completos e independientes con su propio estado, variables, historial, VCS y permisos — son conceptos completamente diferentes.

Integración VCS

La integración VCS conecta un workspace de HCP Terraform con un repositorio de código (GitHub, GitLab, Bitbucket, Azure DevOps). Esta es una característica central del examen.

Pull Request / Merge RequestPlan especulativo (Speculative Plan)

Cuando alguien abre un PR, HCP Terraform ejecuta automáticamente un plan NO aplicable. El resultado se muestra como comentario en el PR para que el revisor vea qué cambiará.

Merge a la rama principal (main)Plan + Apply completo

Cuando se hace merge, HCP ejecuta un plan completo. Dependiendo de la configuración, el apply puede ser automático o requerir confirmación manual.

Push a otras ramasNinguna (configurable)

Por defecto no se ejecuta nada. Se puede configurar para que disparar planes en ramas específicas.

# Configurar workspace con VCS en HCP Terraform:
# 1. Conectar el VCS provider (GitHub App, GitLab, Azure DevOps)
# 2. En el workspace: Settings → Version Control
# 3. Seleccionar repositorio y rama a monitorear

# En el código, conectar con bloque cloud:
terraform {
  cloud {
    organization = "mi-empresa"
    workspaces {
      name = "prod-infra"  # workspace conectado al repo
    }
  }
}

# Para runs locales (sin VCS, iniciados desde CLI):
# terraform plan  → ejecuta en agentes HCP pero iniciado localmente

Ejecución remota y estado remoto

En HCP Terraform, los planes y applies no se ejecutan en tu máquina local sino en agentes de HCP (VMs gestionadas por HashiCorp) o en agentes propios (para Terraform Enterprise).

Ventajas de la ejecución remota

  • • Consistencia: todos los applies usan el mismo entorno
  • • Sin dependencia del entorno local del desarrollador
  • • Los logs quedan centralizados en HCP
  • • Las credenciales no necesitan estar en la máquina local
  • • Historial completo de todos los runs

Estado remoto en HCP

  • • Cifrado en reposo automáticamente
  • • Locking automático durante cada run
  • • Versionado completo (puedes ver estados anteriores)
  • • Accesible desde otros workspaces via terraform_remote_state
  • • Sin necesidad de S3 + DynamoDB
# Leer outputs de otro workspace (terraform_remote_state)
data "terraform_remote_state" "networking" {
  backend = "remote"
  config = {
    organization = "mi-empresa"
    workspaces = {
      name = "prod-networking"
    }
  }
}

# Usar los outputs del workspace de networking:
resource "aws_instance" "app" {
  subnet_id = data.terraform_remote_state.networking.outputs.private_subnet_id
}

Variable sets

Los variable sets son colecciones reutilizables de variables que pueden aplicarse a múltiples workspaces. Evitan duplicar la misma configuración (por ejemplo, credenciales de AWS) en cada workspace.

Caso de usoSin variable setsCon variable sets
Credenciales AWSConfigurar AWS_ACCESS_KEY_ID en cada workspace (50+ workspaces = 50+ configuraciones)Un variable set con las credenciales, aplicado a todos los workspaces de una vez
Tags obligatoriosDefinir TF_VAR_team en cada workspaceVariable set global con las vars de tagging
Config de regiónDuplicar aws_region en cada workspace de producciónVariable set "prod-config" aplicado a todos los workspaces de prod

Sentinel y OPA

Sentinel es el framework de Policy as Code de HashiCorp. Permite definir políticas que se evalúan automáticamente antes de cada apply para garantizar el cumplimiento de normativas.

# Ejemplo de política Sentinel
# Requiere que todos los recursos tengan el tag "Environment"
import "tfplan/v2" as tfplan

# Obtener todos los recursos del plan
all_resources = filter tfplan.resource_changes as _, resource_change {
  resource_change.mode is "managed" and
  (resource_change.change.actions contains "create" or
   resource_change.change.actions contains "update")
}

# Verificar que tienen el tag requerido
has_env_tag = rule {
  all all_resources as _, resource {
    resource.change.after.tags["Environment"] is not null
  }
}

# La política se cumple si la regla es verdadera
main = rule { has_env_tag }
Nivel de enforcementDescripciónQué ocurre si falla
advisoryInformativo. La política se evalúa pero no bloquea.El apply continúa con una advertencia visible
soft-mandatoryObligatorio pero puede saltarse con suficientes permisos.Bloquea el apply. Un usuario con permisos puede hacer override.
hard-mandatoryAbsolutamente obligatorio. No puede saltarse por nadie.Bloquea el apply permanentemente hasta que la config cumpla la política

🎯 Sentinel vs OPA para el examen

Sentinel es el framework nativo de HashiCorp (lenguaje propio). Disponible en HCP Terraform Plus y Enterprise. OPA (Open Policy Agent) es un framework open source que HCP Terraform también soporta como alternativa a Sentinel. Ambos se evalúan entre el plan y el apply. El examen suele preguntar sobre Sentinel y sus niveles de enforcement.

Tiers y características principales

TierRecursos gestionadosRuns simultáneosCaracterísticas extra
Free500 recursos1 runEstado remoto, ejecución remota, VCS básico, registry privado
PlusSin límiteSin límiteFree + Sentinel, SSO, audit logging, variable sets, equipos avanzados
EnterpriseSin límiteSin límitePlus + self-hosted, agentes privados, clustering, compliance avanzado

💡 Cambios de nombre que debes conocer

Terraform Cloud se renombró a HCP Terraform en 2024. El examen puede usar ambos nombres. Terraform Enterprise es la versión self-hosted que se instala en tu propia infraestructura (para empresas con requisitos de compliance que no pueden usar SaaS).

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Un equipo tiene configurada la integración VCS entre HCP Terraform y su repositorio de GitHub. Un desarrollador abre un Pull Request con cambios en la infraestructura. ¿Qué ocurre automáticamente en HCP Terraform?