DEV Community: uttamchaturvedi9

IAC with Terraform

uttamchaturvedi9 — Wed, 20 Aug 2025 19:27:38 +0000

Terraform is an open-source IaC (Infrastructure-as-Code) tool for configuring and deploying cloud infrastructure. It codifies infrastructure in configuration files that describe the desired state for your topology. Terraform allows you to use a consistent workflow over your infrastructure lifecycle, regardless of the resource provider. The infrastructure as code workflow lets your declaratively manage a variety of services and automate your changes to them, reducing the risk of human error through manual operations.

Advantages:

IAC is crucial because it helps to speed deployment and release of software

Terraforms support provide multi-cloud platforms like AWS, AZURE and Google etc..

IAC assist to restrict user to delete resources accidentally

Provide template to write code and use it many times

Unified template also provide security

Workflows

In HCP Terraform, your resources are organized by workspaces, which contain your resource definitions, environment and input variables, and state files. A Terraform operation occurs within a workspace, and Terraform uses the configuration and state for that workspace to modify your infrastructure.

HCP Terraform supports three workflows for your Terraform runs:

The CLI-driven workflow, which uses Terraforms standard CLI tools to execute runs in HCP Terraform.
The UI/Version Control System(VCS)-driven workflow, in which changes pushed to version control repositories trigger runs in the associated workspace.
The API-driven workflow, which allows you to create tooling to interact with the HCP Terraform API programmatically

Init: Validate working directory consisting of terraform config file. This is the first command to be executed after writing new file

Validate: Check for syntax and validate config file

Plan: Create execution plan

Apply: Apply changes and execute command to create resources

Destroy: Remove terraform managed resources. It will ask for confirmation before removing resources

In the below example we will deplyoing resource group using terraform modules with real world scenario

Terraform Module Definition

A Terraform module is a container for multiple resources that are used together.

A module can be as simple as a single resource or as complex as a complete infrastructure stack.

Modules provide a modular structure with a clear separation of concerns, making infrastructure easier to manage, reuse, and maintain.

Example: Deploying a Resource Group with Terraform Modules

In this example, we use Terraform modules to deploy a Resource Group.
The project repository for the Resource Group creation is available here:
https://github.com/uttamchaturvedi9/terraformforcommunity

├── main.tf # Main Terraform configuration
├── variables.tf # Variable definitions
├── terraform.tfvars # variable values
├── modules/ # Terraform modules
│ └── resource-group/ # Resource Group module
│ ├── main.tf # Module main configuration
│ ├── variables.tf # Module variables
│ └── outputs.tf # Module outputs
└── README.md # This file

This repository demonstrates how to:

Define a Terraform module for Resource Group creation.

Use input variables for flexibility.

Apply modular structure for better reusability.

Summary
Terraform, as an Infrastructure as Code (IAC) tool, allows infrastructure provisioning and management through declarative configuration files. By defining resources in reusable modules, teams achieve:

Consistency: Repeatable deployments across environments.

Modularity : Clear separation of concerns, making code reusable and maintainable.

Scalability: Ability to orchestrate simple to complex infrastructure stacks.

Collaboration: Version-controlled infrastructure code shared across teams.

Conclusion
Using Terraform as IAC empowers organizations to manage infrastructure in the same way they manage application code. This approach reduces manual effort, minimizes errors, and accelerates delivery. With its modular design, state management, and provider ecosystem, Terraform provides a scalable, reliable, and automated way to orchestrate infrastructure, making it a cornerstone of modern DevOps practices.

SAS Token - Secure way

uttamchaturvedi9 — Sun, 10 Aug 2025 21:05:36 +0000

Problem Statement
An HTML file stored in Azure Blob Storage was not accessible when opened as a direct link.

The following issues were encountered:
Without authentication, the blob was private and returned Authorization errors.
When accessed via a generated SAS token, the browser attempted to download the file instead of rendering it as an HTML page.
Direct access using a blob endpoint was not possible for users inside the network without special permissions.
The requirement was to make the file viewable in a browser as a web page via a shareable link while still controlling access.

The soultion is SAS tokens

After investigation, the following steps were taken to make the file accessible through a SAS token and open correctly in the browser.

Generate a SAS Token for the Blob

A Shared Access Signature (SAS) token grants time-limited and permission-scoped access to a specific blob without exposing the storage account key.

Steps (Azure Portal):

_Navigate to the Azure Storage Account in the Azure Portal.
Go to Containers → open the target container (e.g., invetoryreport).
Locate and click on the HTML file (e.g., /stockdata/invetoryreport.html).
Click Generate SAS at the top.
Configure:
Permissions: Read (r)
Start time: A few minutes earlier than the current time (to avoid clock skew issues)
Expiry time: As per requirement (e.g., 1 day or 1 week)
Allowed protocol: HTTPS
(Optional) Allowed IP addresses: Specify if restricting to certain networks

Click Generate SAS token and URL.
Copy the Blob SAS URL provided. This URL contains the file path and SAS token parameters._

Set Correct Content-Type for the Blob
By default, blobs may be served with the application/octet-stream MIME type, which forces browsers to download them. To make an HTML file render in a browser, the Content-Type must be set to text/html.

Steps (Azure Portal):

In the blob’s details page, click Properties.
Locate the Content-Type field.
Change the value to text/html
Save the changes.
Congratulations!!!! . Now you can access file directly in browser

Advantages of SAS Tokens

Granular Access Control You can grant access to specific resources (containers, blobs, queues, tables, files) without giving full account keys. Permissions can be fine-tuned (read, write, delete, list, etc.).
Time-Bound AccessTokens can expire automatically, reducing the risk of long-term exposure.
No Need to Share Account Keys Account keys give full access; a SAS token limits scope and reduces potential damage if compromised.
Temporary & Revocable You can revoke access by regenerating the storage account keys or changing stored policies.
Flexible Delivery Tokens can be passed via URLs, making them easy to use in applications, scripts, and APIs without extra authentication steps.
Disadvantages of SAS Tokens
Security Risk if Leaked Anyone with the SAS URL has the permissions until it expires — so tokens must be protected like passwords.
Difficult to Revoke Before Expiry For ad hoc SAS tokens (not tied to a stored access policy), you can’t revoke them without rotating the storage account key.
Potential for Over-Permissioning If not configured carefully, a token might allow more actions than intended.
Expiration Management Short expiry improves security but can cause operational issues if the token expires mid-process; long expiry increases risk if leaked.
Logging Limitations You can see when storage is accessed, but you can’t easily trace the identity of the person using the token — it’s just whoever has it.

💡 Best Practice:

Use stored access policies where possible — they let you revoke a SAS without touching account keys.
Always use HTTPS to prevent token sniffing.
Keep SAS lifetimes short and permissions minimal.

Azure Service Principle

uttamchaturvedi9 — Thu, 15 May 2025 18:29:45 +0000

When I first encountered the term “Service Principal”, I was completely confused.
Was it a user? Was it an app? Was it a login account?
And why did it need its own password or secret key?

If you’re getting started with cloud infrastructure, especially in Azure, the concept of a Service Principal can feel vague and overly abstract.

You’re not alone — many professionals, especially those coming from traditional development or sysadmin backgrounds, struggle to understand:

What exactly is a Service Principal?

When and why should you use one?

In this post, I’ll break it down in plain language, using real-world example and code snippets— so by the end, you’ll never be confused by the term again.

Service Principal is like a user account for apps or services that need to access Azure resources. For example in order to login in the system user need user name and password, similarly its kind of user name and password for the app to access resource in azure

Very Simple Definition:
A service principal is a special account that lets an app or automation tool sign in to Azure and do things, like start a virtual machine or deploy code — but only what you allow it to do.
It’s not a person, but it has its own ID and password (called a client ID and secret), and you can control what it’s allowed to access using roles and permissions.

Scenarios:

1.When You Register an Application in Azure AD
• Scenario: You create an app registration (e.g., for a web app, API, or daemon service).
• Result: Azure automatically creates a corresponding Service Principal in your tenant.
• Purpose: The app can then authenticate and access resources based on the permissions you assign to the service principal.
App Registration = Identity
Service Principal = Role-playing identity inside a tenant

When You Create an Azure Resource That Needs to Access Other Resources Examples: • Azure Kubernetes Service (AKS) • Azure App Service with managed identity . Azure Data Factory with linked services • Result: Azure automatically creates a Managed Identity, which is essentially a Service Principal under the hood.

System-assigned managed identity is tightly coupled with the resource and gets deleted if the resource is deleted.

When Using Azure DevOps Service Connections • Scenario: You create a Service Connection in Azure DevOps to deploy resources to Azure. • Result: Azure DevOps automatically creates a service principal and assigns it the required permissions (e.g., Contributor role). It’s best practice to regularly audit these service principals and rotate secrets if not using managed identity.

Create a Service Principal with permissions to access a specific Azure subscription or resource group.

bash

az ad sp create-for-rbac — name “terraform-deployer” — role=”Contributor” — scopes=”/subscriptions//resourceGroups/”

This command outputs:json
CopyEdit
{
“appId”: “xxxxx-xxxx-xxxx-xxxx”,
“displayName”: “terraform-deployer”,
“password”: “xxxxxxx”,
“tenant”: “xxxxx-xxxxx”
}
These credentials are saved as secrets in your CI/CD pipeline.

Configure Terraform with the Service Principal: In your pipeline or terminal, set these environment variables:

bash
CopyEdit
export ARM_CLIENT_ID=xxxxx-xxxx
export ARM_CLIENT_SECRET=xxxxxxx
export ARM_SUBSCRIPTION_ID=xxxxx-xxxx
export ARM_TENANT_ID=xxxxx-xxxx
Now, Terraform can authenticate to Azure securely and automatically using the Service Principal

Summary
Using a Service Principal (either directly or via Managed Identity) is a secure and scalable way to let your Azure applications access other Azure resources — like Key Vault, Storage, or SQL — without using hardcoded credentials. This approach enhances security, supports automation, and aligns with DevSecOps best practices.