TM1: Infrastructure as Code (Terraform Basics)

Asset Profile

Time Estimate: 75 Minutes Focus: Declarative Automation Learning Goals:

• Understand the core architecture and resource schema of the STACKIT Terraform Provider.
• Implement secure token-based authentication mechanisms for automated CI/CD execution.
• Provision sovereign STACKIT resources deterministically via a git-triggered deployment pipeline.

Why Infrastructure as Code (IaC)?

In modern sovereign cloud environments, infrastructure is never provisioned via manual user-interface interactions. Instead, infrastructure is treated with the same rigor as software source code. Utilizing Terraform within a centralized pipeline framework provides four foundational advantages:

• Idempotency: The structural guarantee that executing the same configuration files multiple times always yields the exact same live environment state.
• Version control: The tracking of all infrastructure mutations within Git repositories, establishing auditability via pull requests and peer code reviews.
• Speed and scale: The capability to deploy hundreds of identical environments across regions with the same minimal operational effort as a single instance.
• Compliance enforcement: The validation of security guardrails, cost controls, and organizational policies before any physical resource is instantiated.

---

The STACKIT Terraform Provider

The official STACKIT Terraform Provider acts as the primary declarative gateway to the STACKIT API platform. It interprets high-level configuration files (.tf) and translates them into predictable, authenticated API requests against sovereign endpoints.

The complete comprehensive schema documentation for all supported resources and data sources is maintained in the official STACKIT Provider Registry .

Provider Core Capabilities

• Resource coverage: Full lifecycle management of high-performance compute instances, virtual private clouds (VPC), block storage, and managed platform services like the STACKIT Kubernetes Engine (SKE).
• Centralized authentication: Native support for short-lived service account tokens, eliminating the risk of hardcoded credentials within engineering environments.
• State isolation: Cryptographically secured state management supporting remote state backends to guarantee a single source of truth and prevent concurrent write collisions.

---

The Automated Pipeline Flow

Within the STACKIT Cloud Framework, execution of Terraform binaries from local developer machines is restricted. All structural modifications must proceed through an isolated, identity-vetted CI/CD pipeline.

1. Code: Define your target state configuration (e.g., SKE clusters, object storage buckets) using standard HCL syntax in .tf files.
2. Plan: The pipeline initiates a terraform plan execution to compute the structural delta, creating a transparent preview of additions, modifications, and deletions.
3. Review: A peer cloud engineer structurally validates the generated execution plan within the pull request interface.
4. Apply: Upon a successful merge to the main branch, the pipeline executes terraform apply to materialize the defined resources on STACKIT.
5. State Preservation: The updated state snapshot is securely pushed back to a centralized remote storage backend.

---

Hands-on: Initializing a Project

To interact with STACKIT resources, the provider must be explicitly declared and authenticated using service account credentials injected via the pipeline context.

1. Provider Configuration

Create a standard main.tf file and specify the required provider block and version constraints:

terraform {
  required_providers {
    stackit = {
      source  = "stackitcloud/stackit"
      version = "~> 0.0"
    }
  }
}

provider "stackit" {
  # Authentication is handled via pipeline-injected environment variables:
  # STACKIT_SERVICE_ACCOUNT_TOKEN
}

2. Project Resource Definition

The stackit_project resource establishes the logical organizational tenant container within the sovereign STACKIT platform topology:

resource "stackit_project" "enterprise_core" {
  name         = "Framework-Core-Infrastructure"
  container_id = "your-target-parent-folder-or-org-id"
}

3. Optional Enterprise Security and Network Integration

Depending on your organization’s specific compliance blueprints, projects can be enhanced with advanced framework security patterns at the customer’s discretion:

• SNA architecture patterns: Integration with the Secure Network Architecture can be implemented if specific customer governance models require strict network isolation.
• Supply chain scanning: Pipeline configurations can integrate automatic Helm and Terraform scanning engines (such as Snyk) to identify configuration drift and vulnerabilities.

SNA Reference Architecture

While Secure Network Architecture (SNA) is completely optional and driven by individual customer architecture blueprints, it is highly recommended for high-security or regulated environments. For implementation details, consult the dedicated landing zone documentation at [/migration/design-and-mobilize/landing-zones/network-architecture/].

---

Official Provider Reference

Code & registry registry.terraform.io STACKIT Terraform Provider Documentation Browse the complete resource and data source schema of the official STACKIT provider on the Terraform Registry. Open the repository