Forem: Vivekanand Rapaka

Istio Ingress gateway vs Istio Gateway vs Kubernetes Ingress

Vivekanand Rapaka — Thu, 29 Dec 2022 23:15:30 +0000

Objective

Network Traffic management is one of the key areas for any kubernetes setup and its important to understand how different components of your cluster function when it comes to handling the incoming traffic.

The main objective of this post is to discuss about components of nginx ingress controller and Istio service mesh and the main differences between each of them along with following:

Different types of services used in a kubernetes cluster
What is an ingress controller?
What is an ingress resource?
What is an istio service mesh?
Traffic flow in Nginx Ingress Controller vs Istio service mesh.
When to use Istio Service Mesh vs Nginx Ingress controller?

Services in kubernetes - A quick recap

Before knowing about Nginx ingress controller and Istio service mesh, its important to know about concept of services in a native kubernetes setup.

If you have worked on kubernetes or have learnt the basics of kubernetes, you must be familiar with object type called "service".

In order for your workloads hosted on pods to be able to accept traffic, you would need some kind of load balancer. All the pods we deploy are ephemeral, which means when a pod is terminated or killed, it will be replaced by another pod with different ip address and we cannot directly communicate with the POD instead we use the concept of service object.

A service is a logical abstraction to expose the deployed pods that host your application. Below are few different types of the services that are commonly used.

NodePort
ClusterIP
LoadBalancer
ExternalName

Depending on the type of service you choose, traffic will be routed accordingly. I'll briefly touch upon what each of these services does.

NodePort

When you use this kind of service object, kubernetes would create a random port in the range of 30000-32768 on each of the nodes and you can access the backend pod by typing the IP address of the Node followed by the port as follows:
http://192.168.126.8:32768

Below is the YAML file for node port service

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: MyApp
  ports:
      # By default and for convenience, the `targetPort` is set to the same value as the `port` field.
    - port: 80
      targetPort: 80
      # Optional field
      # By default and for convenience, the Kubernetes control plane will allocate a port from a range (default: 30000-32767)
      nodePort: 30007

If you have multiple nodes, each node will have it own IP and you would need to use the IP address and the port number to access your workload. This is good for testing purposes and local development, but not ideal for real world scenarios.

ClusterIP

This is one of the common services that is used to create and expose your workloads within your cluster. Unlike nodePort service, you have an option to choose which port you would like your kubernetes cluster to allocate the port number. When you create a clusterIP type of service, it would create a service object with an IP and port number specified and you can use the same IP/DNS service name allocated to the service across the cluster to access your cluster. When you create a service object, if you do not specify the type of service you would like to create (ex:clusterIP/NodePort/Loadbalancer), by default kubernetes would create the service of type clusterIP.

Below is the YAML file snippet from kubernetes.io for service of type clusterIp.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

This type of service does not expose your workloads outside your kubernetes cluster and its good for workloads like backend API Services, Databases, Batch processing workloads, etc.
Typically the services which you dont need to be expose to external world are created as clusterIP.

Load Balancer

This is one of most commonly used services that is used to expose your workloads to external world and on cloud. When you use this kind of service, kubernetes would spinup a load balancer in the cloud service provider where your managed kubernetes cluster is hosted on and it creates an IP Address in the cloud, which you can access it externally from your kubernetes cluster. This is one of the service types that are used for exposing your front-end services. You can also specify the ip address you would like to assign to your service.

Below is the YAML file for Load Balancer

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.2.127

ExternalName
Services of type external name point a service to a DNS name instead of pods based on pod selector like other type of services described above.

Below is yaml file that shows how to define an external name service

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

To learn more about these services in detail follow this link

What is an Ingress Controller and why do we need one?

Now that we have covered the basics of kubernetes services, lets move on to Nginx Ingress controller.

One of the services we discussed above is Load Balancer, while you can use this kind of service to expose your workloads, this is good of a couple of different workloads. However, when your microservices grow, to expose them externally, you need to use multiple services of type load balancer and each of these services would create an additional load balancer and a public IP on your cloud service provider and you would end up not only managing all of them, but also you would be paying for each of the public Ips provisioned by load balancer service.

Here is where, Ingress controller comes into picture.

An ingress controller is a piece of software that provides reverse proxy, configurable traffic routing, and TLS termination capabilities for Kubernetes services. Kubernetes ingress resources are used to configure the ingress rules and routes for individual Kubernetes services.

When you use an ingress controller like nginx ingress controller, you dont need to create multiple load balancer type services to expose your workloads. When you create an Nginx ingress controller, it would create a service type of Load balancer and you can use it as your inbound ip to access all your workloads by exposing them on clusterIP type of service. But how do we create a single service type and route the traffic to multiple backend services? that can be achieved using an Ingress Resource. An ingress resource is another kubernetes object that is used to define how the incoming traffic can be forwarded to appropriate backend service and the traffic sent to service would be directed to the pods.

I'm going to deploy a sample hello-world application on an AKS cluster, install nginx controller and configure ingress resource to route the traffic. While i'm not going to cover everything in detail on this setup, i used followed this link to install ingress controller on AKS and its pretty straight forward.

I have created an AKS cluster and deployed sample application on it in a new namespace called 'ingress-namespace'.

Then installed a nginx ingress controller, it created few kubernetes objects in 'ingress-basic' namespace.

One of them you see is a service type of load balancer that accepts the incoming traffic.

What is an Ingress Resource?

An ingress resource one of the resource types that helps in defining the routing to your backend services. There are two types of routing methods available in ingress.

1.Host-based routing
2.Path-based routing

Using an ingress resource you can map the incoming requests to respective backend services.

Below is an ingress resource YAML file that shows ingress routing rule for based on host name. There are two hosts defined the the resource. If the incoming request is https://foo.bar.com/bar where host name is "foo.bar.com" and prefix is "/bar", it goes to "service1" and requests for "*.foo.com" with prefix "/foo" goes to "service2". This type of routing is called host-based routing.

code snippet credits: Kubernetes.io

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wildcard-host
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
      - pathType: Prefix
        path: "/bar"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: "*.foo.com"
    http:
      paths:
      - pathType: Prefix
        path: "/foo"
        backend:
          service:
            name: service2
            port:
              number: 80

Below is an ingress resource YAML file that shows how the routing happens on incoming request for application path with prefix '/testpath'. That means, if there is an incoming request, for https://myexamplesite.com/testpath it will be evaluated against below ingress rule and it would be sent to the service called test on port 80. This path based routing.

code snippet credits: Kubernetes.io

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

Traffic flow when you use Ingress Controller and Ingress resource

Here is a picture on how the incoming traffic flows when you use ingress.

Image credits: kubernetes.io

Traffic flow explained:

Request originates from client reaches ingress-managed load balancer
Then request is processed by Ingress resource based on the service prefix defined in the routing rule.
Then request is sent to the actual service
Then the request is sent to the actual backend pod.

Now that we have taken a look at ingress and other options in ingress, lets go few concepts of Istio and how they are different from traditional ingress controller.

What is Istio?

Istio service mesh is one of the widely used service mesh tools and it has capabilities like observability, traffic management, and security for your microservices workloads hosted on your kubernetes cluster. For more information on istio vist https://istio.io/latest/about/service-mesh/

What is an Istio IngressGateway?

Istio Ingress Gateway is one of the components that is operates at the edge of the service mesh and serves as traffic controller incoming requests. Interestingly, this also installed as one of the 'service' object and has few pods running behind it. So basically the logic to handle the traffic in the pods that run the istio ingressGateway and istio uses Envoy proxy images to run these pods. This is similar to plain Nginx Ingress Controller.The Ingress Gateway Pod is configured by a Gateway and a Virtual Service.

What is an Istio Gateway? And how is it different from Ingress Controller?

Istio Gateway is the component is similar to ingress resource. Like the way ingress resource is used to configure ingress controller, Istio Gateway is used to configure Istio Ingress Gateway which is mentioned in the above section. Using this component, we can configure it accept traffic on the host that we want the traffic to be sent on, configure TLS certificates for incoming requests.

Below is the yaml snippet of istio gateway component. Here it shows that in the selector, it uses istio: ingressgateway as the label to bind to istio ingress gateway and this is how its bound to istio gateway. It also has the 'servers' section which has the configuratio for configuring the port number, hosts that this gateway is configured to accept traffic on.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "httpbin.example.com"

What is a Virtual Service?

A virtual service is used to configure routing to the backend services. We can configure one virtual service per application and the backend services.

Below is the snippet of virtual service component, that shows how its configured to route the traffic to backend 'service' based on incoming hosts and uri prefix.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews.prod.svc.cluster.local
  http:
  - name: "reviews-v2-routes"
    match:
    - uri:
        prefix: "/wpcatalog"
    - uri:
        prefix: "/consumercatalog"
    rewrite:
      uri: "/newcatalog"
    route:
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v2
  - name: "reviews-v1-route"
    route:
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v1

Traffic flow when you use Istio Ingress Gateway with Istio gateway and Virtual Service

Below picture shows how the traffic flows in Istio and also shows how the services are configured.

When to use Istio service mesh vs Nginx Ingress Controller?

So far we have seen the differences between a traditional nginx ingress controller vs istio service mesh. Using service mesh over ngnix ingress controller is recommended only if you are looking for:

Enabling mutual TLS between services
Observability of your service traffic
Implement deployment techniques like blue/green, circuit breaking, A/B testing, etc

Use traditional nginx ingress controller, only if you want to handle your incoming traffic and distribute it to backend services, which is good for services with less number. When your workloads/services increase, using service mesh tool like ISTIO service mesh is essential.

In this blog post, we covered differences between a traditional ingress gateway vs istio service mesh and when to use each of them.

This brings us to the end of this article.

Thank you for reading this post and I hope you find it informative.

Happy Learning!!!

CMK Encryption for Azure Storage Accounts

Vivekanand Rapaka — Wed, 26 Jan 2022 12:56:34 +0000

Purpose of this post

The purpose of this post is to show you what kind of encryption Microsoft uses for encrypting storage accounts by default and how you can use CMK (Customer Managed Keys) to encrypt your storage accounts.

Encryption using Microsoft managed keys

By default, if you don't specify the type of encryption for your storage accounts while creation, Microsoft uses server-side encryption (SSE) to automatically encrypt your data. This is applied to any storage account regardless of its tier. Microsoft uses Microsoft managed keys for this type of encryption. This is the default option from Microsoft.

Encryption using Customer managed keys (CMK)

While you can continue to let Microsoft handle the encryption of your data, customers can use their own keys to handle data encryption. This type of encryption is called CMK enabled encryption. Here are some of the benefits of using CMK over default Microsoft managed keys.

Customers have control over the keys used to encrypt their data.
Microsoft rotates their keys as per their own compliance requirements. Customers using CMK can meet security compliance requirements.
CMK keys are stored in customer's key vault, giving control over where these can be used.
Same CMK keys can be used to encrypt multiple storage accounts.

Implementing CMK for storage accounts

In this section, we'll see how to implement CMK for storage accounts.

Examining default encryption for a storage account

Before implementing CMK, lets see how Microsoft encrypts storage account with Microsoft managed keys. While creating a storage account in the 'encryption' section, you can specify whether you would like go with default encryption or a customized encryption using CMK.

Once its created, you can see the type of encryption used by storage account as shown below:

If you would like to use CMK, you can do so, however the a new key has to be created and stored in Azure Key Vault and used for encryption. We'll see that in the next section.

Enabling CMK for a storage account

1.Create a new key in Azure key vault in the same region as storage account
2.Click on 'generate/import' under keys as shown below:

3.Give key a name and leave everything else to default as shown below.

4.Go back to storage account and encryption section.

After selecting the key it should show as following. Click 'save' to apply the settings

Once applied it would show that it is now using CMK for storage encryption.

As a part of this applying CMK encryption for storage accounts, it also creates a system assigned managed identity to the storage account and same is granted permission Azure Key Vault with 'get', 'wrap' and 'unwrap' permissions for the managed identity of storage account.

In this blog post, we have seen how to use customer managed keys for storage account encryption.

This brings us to the end of this blog post. Hope you enjoyed reading it.

Happy Learning!!!

Access Secrets in AKV using Managed identities for AKS

Vivekanand Rapaka — Mon, 17 May 2021 18:29:15 +0000

Purpose of this post

The purpose of this post is to show you how to access secrets from AKS cluster that are stored in Azure Key Vault.

In one of my previous blog posts, i have shown how to access keys from Key vault from Azure DevOps, where i have configured the release pipeline to fetch the secret from key vault and substitute it during runtime for the pipeline.

we have many other ways of accessing keys from key vault from any of the Azure resources we deploy, Using managed identities is one of the secure and easy ways to access to keep our app secure.

What are Managed Identities?

There are a lot of posts that are there which helps you understand what a managed identity is. If you go to Microsoft docs, here is the definition of managed identities you will get.

"Managed identities provide an identity for applications to use when connecting to resources that support Azure Active Directory (Azure AD) authentication. Applications may use the managed identity to obtain Azure AD tokens. For example, an application may use a managed identity to access resources like Azure Key Vault where developers can store credentials in a secure manner or to access storage accounts."
Definition credits: Microsoft docs

In simple words, any azure resource that supports azure ad authentication can have managed identities. Once we enable managed identity for an azure, a service principal will be created in active directory on behalf of that azure resource you create.
With this, you can grant access to the an Azure resource that has managed identity enabled on the target azure resource you want to access.

For example, if you want to have a webapp access your key vault, all you need to do is to enable managed identity on your webapp and grant access to the managed identity of your webapp in the access policies of the key vault.

Without managed identities, in the above mentioned scenario you would need a service principal and a client secret to be created for your application (webapp in above scenario), and that service principal has to be granted permission on the target azure resource (key vault in above scenario). You need to configure your webapp to use the client id and secret to make calls to key vault to fetch the secrets.

You would have to manage the client id and secret by yourself. Incase if the service principal credentials are compromised, you need to change the secret every time and update the application code to consume the new secret. This is not only a bit insecure, but also tedious to update client secrets in multiple places.

Managed Identities to rescue

With managed identities you no longer have to create a service principal for your app, but when the feature is enabled on the azure resource, it will not only create an SP for you, but also it would manage rotation of keys by itself. You no longer need to keep client id and client secret of your service principal in your source code to access the target resource.

Kindly note that we are removing the burden of maintaining the service principal credentials in your code.
But you still need to have appropriate libraries and respective code to access the target resource. For example, if your app is going to access key vault and if the app is going to be on a webapp with managed identity enabled, you no longer need to pass the service principal credentials to call the key vault api endpoint. You can call the key vault api endpoint directly from your webapp as it has managed identity enabled and that managed identity is granted permission on the key vault.

With that, Lets dive into some demo.

Here are the steps we are going to follow:

Create an AKS cluster
Enable managed identity to AKS cluster
Create a key vault with a secret in it.
Enable access to managed identity of AKS via access policies in key vault.
Access the secret in the key vault from a Pod in AKS.

We are going to create 2 resources in this demo.

AKS Cluster
Azure Key Vault

In this demo, i have created a sample AKS cluster using following commands after i have logged in to Azure from my azure cli



az group create --name yourresourcegroupname --location uksouth 
az aks create -g yourresourcegroupname -n MyAKS --location uksouth --generate-ssh-keys

As we are discussing about managed identities and not about AKS, the above should suffice for creating an AKS cluster.

Once AKS cluster is created, you should see a new resource group created with name "MC_" this is for the underlying resource your AKS cluster needs to function.

Once its created, click on the VMSS that was created for your AKS cluster.

Once in the VMSS blade, click on the identity and notice that we have option for System Assigned managed identity.

Enable it by click on "on".

Once its enabled, you should see a new managed identity resource created in the "MC_" resource group.

Next create and Azure key vault resource and secret in it.

az group create --name "yourresourcegroupname" -l "locationofyourresorucegroup"

I have created below key vault and a secret.

As of now, we have created an AKS cluster, enabled system assigned managed identity and created a Key Vault with a new secret in it.

Next, we are going to add permission to AKS to access key vault. To do so, go to access policies of Key vault and click on "Add access policy" option.

Select "secret management" in the configure from template option.
Note that i have selected "secret management" for the sake of this POC. In real production environment, get, list permissions should be enough.

In the "Select principal" option, click on "none selected" to select one and choose "AKS Service principal" Object ID and "add".

You should see the access policy added in the list of access policies and click 'save'.

Once done, connect to AKS Cluster using below commands

az aks get-credentials --resource-group yourresourcegroupname --name youraksclustername --overwrite-existing

Once done, spin up an nginx pod using below commands.

use following command to login to the pod interactively

kubectl exec -i -t nginx --container nginx -- /bin/bash

To access the secret key in azure key vault, we need to hit the api to obtain the access token as described in this document.

Once the token is obtained, you can access the secret key value in the key vault using below command.

curl 'https:///secrets/?api-version=2016-10-01' -H "Authorization: Bearer "

This way we can access the values in the key vault from AKS with managed identities enabled.

In this blog post, we have seen what managed identies are in a nut shell and seen how to enabled managed identity for AKS cluster and access the key vault from AKS cluster with help of access policy granted to managed identity of AKS cluster.

System Assigned managed identity lives as long as the resource is in Azure. Once the resource is deleted, the corresponding managed identity and its service principal are also deleted from Azure AD.

We also have whats called an User identity which exists even after a resource is deleted and you can assign it to one or more instances of an Azure service. In the case of user-assigned managed identities, the identity is managed separately from the resources that use it and you are responsible for cleaning it up after use.

Hope you enjoyed reading this blog post.

Thanks for reading!!

Using Azure Keyvault for Azure Webapps with Azure DevOps

Vivekanand Rapaka — Fri, 19 Mar 2021 16:44:28 +0000

Purpose of this post

The purpose of this post is to show you how we can use Azure Key Vault to secure secrets of a webapp and call them from Azure DevOps using Variable groups. This is one of the ways to handle secrets for your deployments. One of the other ways is to use Managed Identities which is more secure. I'll cover that in a different blog post.

What are secrets and why is secret management important?

Secrets management is the process of securely and efficiently managing the safe usage of credentials by authorized application. In a way, secrets management can be seen as an enhanced version of password management. While the scope of managed credentials is larger, the goal is the same — to protect critical assets from unauthorized access.

For managing sensitive application configuration like DB connection strings, API Keys and other types of application related sensitive keys. It is recommended to use Azure Key Vault or any other secret management solution for storing secrets. Azure Key Vault is a cloud service for securely storing and accessing secrets like connection strings, account keys, or the passwords for PFX (private key files). Azure Key vault can be used for all commonly used services like Azure Webapp, Azure Kubernetes, Azure Virtual Machines and many other Azure Services.

Data like connection strings, API tokens, Client ID, Password are considered as sensitive information and handling them poorly may not only lead into security incidents but also my compromise your entire system.

Here are a couple of poorly handled secret management practices.

Maintaining secrets in source code repository in a settings or environment config file
Having same password/keys for all the environments
Secrets are shared across all the team members
Teams using service accounts to connect to the database or a server

Avoiding the above would be the first step for an effective secret management.

Using Azure KeyVault for App Services

Using Azure DevOps, All the sensitive data like Connection Strings, Secrets, API Keys, and any other data you categorize as sensitive. These values can be fetched directly from Azure Key Vault, instead of configuring them on pipeline.

Let’s take an example of configuring DB Connection string for an Azure WebApp using Azure KeyVault.

Lets create a KeyVault along with a secret in it. Notice that the key value is secret.

Similarly, lets create one more for UAT DB connection. Once created, it will show the keys created as in below screenshot.

Now in Azure DevOps, create a new variable group under the library section of pipelines.

Give variable group a name
Make sure to select the options “Allow access to all pipelines”, “Link secrets from Azure KeyVault”.
Choose KeyVault name and authorize.
Click on “Add” and select secrets for using them in the pipeline.

Below is the screenshot for reference.

Once done, in the pipeline, go to variables section click on ‘Variable groups’ and click on ‘Link variable group’ to choose the variable group that is created.

In the stages, select the environments and click link option.

Now the next step is to configure the task for applying the DB connection string to the app service.

Add and configure “Azure App Service Settings” task and in the connection strings settings, configure the JSON value for applying DB Connection string. The value here is $(Dev-DBConnectionString) that is stored in Azure KeyVault. It is picked up by the pipeline during the execution.

Below are the logs of the execution for the pipeline. Here it shows that the pipeline is able to fetch the value and it being a sensitive parameter, value of DB connection string is hidden in the logs.

In the webapp, under configuration->Database connection strings, we will be able to see the actual value.

Once we click on the ‘show values’ we can see the value of connection string.

For configuring the other application settings which are NON-SENSITIVE, we can use ‘App Settings’ Section of “Azure App Service Settings” task to configure application settings, similar to DB Connection strings, we can use the values from key vault as well.

During the execution, we can see that application key that is configured in the above setting.

The other way to manage secrets without key vault is to use variable and the padlock option to lock the key value as shown in the below screenshots.

This way the secret is not visible to anyone, but if you would like to know the value, you need to other ways to handle it, the suggested approach is to implement a solution like Azure Key Vault with right access polices.

This brings us to the end of this blog post and we have seen how to use Azure Key Vault for Azure Web Apps with Azure DevOps and various options available to handle secrets in Azure DevOps using Variable groups and Variables.

Hope you enjoyed reading it. Happy Learning!!

Importing Existing Infrastructure to Terraform

Vivekanand Rapaka — Sun, 22 Nov 2020 05:38:10 +0000

Cover page image credits to: terraform.io

Purpose

The purpose of this blog post is to show you how to import already deployed infrastructure in azure by other means under Terraform control.

Assumptions

I assume that you have basic knowledge on Azure & Terraform.

Need for import

Terraform is a IaC tool that lets you to manage your infrastructure regardless of where its hosted (on-premises or cloud) and how its deployed (manually deployed or by other IaC tools like ARM Templates). In case of Azure, you might run into a scenario where the existing infrastructure is already deployed and your team or organization has decided to use Terraform for managing the infrastructure going forward. In such scenario, you need to bring existing infrastructure under Terraform’s control.

In this blog post, we’ll see how to achieve this on an existing infrastructure that’s already deployed on Azure. Here are the steps that are involved in importing the deployed infrastructure.

Identify the resources that you want to import to Terraform.
Write the configuration for deployed resource.
Run ‘Terraform Import’ to import the changes to a state file.
Run ‘Terraform Plan’ to review the changes between the Terraform configuration and actual state.
Make the changes in configuration to include the missing changes, run ‘Terraform Plan’ again to make sure that configuration includes all the attributes from deployed infrastructure.

Please note that when I refer to the word configuration, I mean the terraform template file (.tf) that we use to declare our desired state configuration

Let’s get started.

I have following resources deployed in my resource group from a different deployment.

App Service Plan
WebApp with Staging Slot
Application Insights
Storage Account

In order to import these resources, we’ll have to create a terraform configuration file that includes all these components. Let’s start with App Service Plan. We’ll refer to the documentation of terraform resource for azurerm_app_service_plan

I created a new created a new main.tf file and copied the above block to it and added azurerm provider on top of it and also updated the values from existing infrastructure.

provider "azurerm" {
  version = "2.0.0"
  features {}
}

resource "azurerm_app_service_plan" "example" {
  name                = "plan-sp-dev"
  location            = East US
  resource_group_name = “az-terf-dev-rg”

  sku {
    tier = "Standard"
    size = "S1"
  }
}

Details of the service plan can be obtained from overview in the resource blade of app service plan.

let’s initialize terraform using terraform init command to install the azurerm provider.

As a first step to import the resource, we wrote the configuration. To identify the command associated with importing a particular resource, we would have the import command in terraform documentation for that resource.

Here is the command syntax:

terraform import azurerm_app_service_plan.instance1 /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/mygroup1/providers/Microsoft.Web/serverfarms/instance1

If you observe carefully, terraform import command is followed by the resource_type which is azurerm_app_service_plan and the resource identifier name which is instance1. There are the values from the configuration file in current terraform’s working directory.

So, it’s important that we write the configuration first and the import process is dependent on it and terraform import doesn’t create a configuration file by itself.

Transforming the import command we obtained above to current implementation, the command we should use is as follows:

terraform import azurerm_app_service_plan.appserviceplan /subscriptions/yoursubscriptionidgoeshere/resourceGroups/az-terf-dev-rg/providers/Microsoft.Web/serverfarms/plan-sp-dev

After running the above command, it shows that the App Service Plan resource import is successful and going forward, this resource will be managed by Terraform.

We need to make sure that next apply doesn’t do any breaking modifications. Let’s run ‘Terraform Plan’ to view the changes between the configuration we wrote and the current state.

From the above screenshot we can see that it now says that our configuration matches the current state of service plan. This means we can safely run ‘terraform apply’ now if we want to.

Let’s do the same with other resources as well. We’ll import app service by adding the configuration in existing main.tf file.

I took the configuration block from terraform documentation and added it by removing “site_config” section as I don’t have any custom site config for my site.

I need app_service_plan_id and that can be obtained from app service plan properties.

resource "azurerm_app_service" "appservice" {
  name                = "app-dev-webapp"
  location            = "EastUS"
  resource_group_name = "az-terf-dev-rg"
  app_service_plan_id = "/subscriptions/yoursubscriptionidgoeshere/resourceGroups/az-terf-dev-rg/providers/Microsoft.Web/serverFarms/plan-sp-dev"
}

Here is how my configuration file looks like so far.

Let’s try to import this resource and check. The procedure to find the command for importing is same as service plan. Syntax is as follows:

terraform import azurerm_app_service.instance1 /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/mygroup1/providers/Microsoft.Web/sites/instance1

Let’s run a terraform import.

Let’s take a minute to examine the. tfstate file that got updated after terraform import command. Every time the import command is run, it would update the state file with the attributes that terraform imported for. So we haven’t mentioned the app insights key information in our configuration, but terraform state file got updated with all the attributes that were set during the manual deployment of this resource. So we need to add the app insights instrumentation key in our configuration file.

If we omit this, terraform would still show that there are no changes to be applied, however if someone changes this key, it won’t be under terraform’s control to revert the change back.

So we need to identify all the configs that we need to control via terraform and add them in our configuration file.

Now if we run terraform plan it should show no changes to the existing infrastructure.

Incase if you see any changes in the output of terraform plan, make sure that you identify and correct the changes. Once the changes are correct, run ‘terraform plan’ to make sure that there are no new changes to be applied.

Similarly, we can do the same for other resources as well. Let’s add staging slot with different name to see how it will show the changes and we can take a corrective action.

Name of the staging slot is ‘webappname-staging’

I’ve added the slot configuration & intentionally gave the name wrong to identify the different after we run import & plan commands.

Here is the output of terraform import command.

Import command will succeed regardless of the name in terraform configuration as we gave the correct name in the terraform import command.

Now, terraform plan shows that there is a change 1 to add and 1 to destroy.

In the output, it clearly shows that there is a change which is forcing the replacement.

So, it’s important that we check the configuration thoroughly before running the plan.
Let’s correct the configuration by changing the name from “staging-test” to “staging” and run ‘terraform plan’ again.

In the same way, we can import other resources (storage account, app insights)

While, app insights import and plan commands ran as expected, storage account resulted in showing that there is a new change.

I haven’t changed the account replication type to “LRS” which is the current setting for the storage account.

I’ve changed the configuration back to “LRS” and it showed no new changes.

We have seen how to import the configuration by hardcoding the values in a single configuration file. However, the best practice is to maintain separate variables file and individual module based architecture of all components you wish to deploy.

Check out my other blog post on how to integrate terraform with DevOps and deploy to various environments with ease with module based architecture.

Here are key take-aways for importing existing infrastructure to terraform:

1.Write the configuration first for the resources you would like to import into terraform state.
2.Terraform import process is dependent on the configuration we write.
3.Import command can be found in the resource documentation and the bottom of the page.
4.Always review the statefile to identify the attributes & the values that were imported.
5.Make necessary changes to your configuration file based on the state file review.
6.Run terraform plan to make sure that there are no breaking changes.

It’s always a best practice to source control terraform configuration files and store the state file in remote back end.

This brings us to the end of this blog post. Hope you enjoyed reading it.

Happy Learning!!!

Magic with Azure DevOps PowerShell Module

Vivekanand Rapaka — Thu, 12 Nov 2020 08:51:31 +0000

Purpose of this blog post

To show you how to use AzureDevOps PowerShell module to achieve some basic tasks that you can do using PowerShell.

Assumptions

I assume that you have fair knowledge on how to use PowerShell for day-to-day operations and some practical working experience on Azure DevOps.

Prerequisites needed

Here are a couple of prerequisites you need if you would like to replicate below in your environment

PowerShell (Obviously) - Its suggested that you have latest and greatest version of PowerShell, but any PowerShell version after 5.1 works just fine.
AzureDevOps PowerShell module – I’ll show you how to install this in this blog post.
Azure Devops Account - With few build & release pipelines setup. check out one of my previous blog posts on how to setup an end to end Azure DevOps Pipeline

AzureDevOps PowerShell Module

AzureDevOps module is open-source PowerShell module, first released in the year 2017. It is owned and maintained by Donovan Brown (Principal DevOps manager at Microsoft) and Sebastian Schütze (Azure Nerd with focus on DevOps and AzureDevOps). and there have been many new versions to it. The current version as of this article is 7.1.2.

If you are an infrastructure engineer or developer, I’m sure that you have used PowerShell in past and the capabilities that you get with PowerShell are simply awesome. Other than the native cmdlets available with default in-built modules available in PowerShell, there are lot of community-driven/open-source modules available for achieving desired actions.

Once such module is AzureDevOps PowerShell module.

Just like any other PowerShell module for respective functions, you can use the cmdlets in this module to interact with REST API of Azure DevOps for all the aspects of Azure DevOps. We already have AzureDevOps CLI offered by Microsoft and it does the same.

If you are a PowerShell fan like me, you would look for a module that offers cmdlets for respective functions for any of the technologies.

To know more about Azure DevOps Powershell Module, please visit following link

AzureDevOps module on Powershell gallery

AzureDevOps module in Choclatey

Ok, Let’s get started.

First, we’ll take a look at how to install AzureDevOps module and the capabilities this module offers. It’s pretty straight forward.

We need a PAT (personal access token) from Azure DevOps to consume it from the cli. So, we’ll generate that first and then install the PowerShell module.

1.Login to your Azure DevOps organization and generate personal access token for your account

2.Select “New Token” and give it a name, choose full access.

NOTE: Do not share this token with anyone. Anyone who has this token has access to your AzureDevOps account.

3.Copy the token and secure it. You need to use it later.

READ the warning message

4.Run PowerShell as administrator and run following command:
Install-Module -Name VSTeam
(run it with –force parameter to upgrade to latest version if the module is already installed)

You see that I already had the module, I ran with ‘-force’ parameter to upgrade it.

5.Assign the Personal access token generated in the previous step to a variable for easy reuse.
$PAT="yourtokengoeshere"

6.Type following commands to set up your account:

Import-Module VSTeam Set-VSTeamAccount -Account https:// https://dev.azure.com/yourorganizationname/ -PersonalAccessToken $PAT

7.Let’s list the projects in the Azure DevOps.
Get-VSTeamProject # Lists all the available Projects.

8.Let’s set a project to a $project to a variable and use below cmdlet for exploring the build definitions, etc.

you can use any of your projects from previous output

$Project='Terraform'

Get-VSTeamReleaseDefinition -ProjectName $Project

I have one CD release pipeline, that its showing in the above output.

9.Let’s explore a little more. How about exporting the variables for this release definition?

Type the following command to get the variables.

Get-VSTeamReleaseDefinition -ProjectName $project -Id 1 | Select -expand Variables | Format-List

Great, we can see the variables in output. Now let’s see the variables from release pipeline to verify.

Looks like we received only the release-scoped variables alone.

Let’s see on how to obtain values for scope for ‘Dev’

Let’s pipe our previous cmdlet to Get-member to see if there exists a property for environments.

We have an environment Property. Let’s expand on that.

In the above output, we can see the variables which are scoped to ‘Dev’

10.Now, let’s run following command to get environment details for respective environments

Get-VSTeamReleaseDefinition -ProjectName $project -Id 1 | Select -expand environments | Where name -like 'DEV' | Select -Expand Variables | Format-List

In the above output we can see the variables scoped for ‘Dev’ environment.

Similarly, if you have additional stages, you can provide the environment name in the above command to retrieve the values. This is especially helpful when you want to extract the variables and store it for future reference.

This brings us to the end of this blog post.

There are many other cmdlets that we can use to play around and get a lot done with help of this module. We can write scripts or a simple one liner to trigger the releases, create reports based on the release run, etc.

I highly encourage you to go through the various other cmdlets available for use by typing Get-Command.

Also, Here is the GitHub link for the module and it has detailed documentation on how can you can contribute to it.

Thanks for reading this blog post, happy learning!!!

SonarCloud Quality check and Pre-deployment Gates with Azure DevOps

Vivekanand Rapaka — Sun, 01 Nov 2020 18:24:06 +0000

Purpose of this blog post

In my previous blog post on DevSecOps with Azure DevOps, I’ve explained about how we can integrate various security tools in Azure DevOps. SonarCloud is one of them. I’ve also mentioned that we can use SonarCloud quality gates as one of the pre-checks for deployment to any of the stages.

In this blog post, we’ll see how we can add SonarCloud as one of the Pre-deployment Gate checks before we deploy it to any of the environments.

Pre-Deployment Approvals, Gates and Manual Intervention

There are three types of checks that can be used to control our release deployment in Azure DevOps.

Lets quickly recap on what those are:

Pre-Deployment Approvals: We add someone from our team as an approver for the release to be promoted and deployed to a specific stage. Once the deployment is approved, the release is processed. This is helpful when you would someone from your team to do a review of the deployment that is about to be performed. A good example would be, a test engineer needs to approve the deployment to Production only after all the bugs in Pre-Prod are remediated. You can add more than one approver for a release.

Pre-deployment gates: We can perform some pre-checks to make sure that the defined requirement(s) are met prior to the deployment of the code into your infrastructure. These are mainly used when you need to connect to external services and get health signal from external services and then promote the release only after the desired health check is met. Typically, gates are used in connection with incident management, problem management, change management, monitoring, and external approval systems.

Manual Intervention: Sometimes, you may need to introduce manual intervention into a release pipeline. For example, there may be tasks that cannot be accomplished automatically such as confirming network conditions are appropriate, or that specific hardware or software is in place, before you approve a deployment. You can do this by using the Manual Intervention task in your pipeline.

To know more about these, follow the below link from Microsoft documentation

https://docs.microsoft.com/en-us/azure/devops/pipelines/release/approvals/?view=azure-devops

SonarCloud Quality gate check:

We have configured SonarCloud analysis in our previous blog post and here is how it looks like.

We need to install SonarCloud extension from market place, configure it in Azure DevOps and add above tasks.

Publish Quality Gate Result would query the rest api of SonarCloud and get the code analysis and show it in the results section.

To see how to add and configure SonarCloud, please follow my previous blog post here

Once the build is triggered and successfully run, it would show the results in the extensions tab.

Now on to how we setup Pre-Deployment Gates, click on release pipelines and then

Click on the Pre-deployment actions button
Click on gates and enable it.
Select ‘Check SonarCloud Quality Gate status’ and enable it.

Here is how it would look like once its enabled.

Go-ahead and create a new release and you can observe that its executing the Pre-Deployment gates.

It’s going wait on the default delay of 5 mints before evaluating the gates. You can change the default evaluation time out in the ‘evaluation options’ part of the Pre-deployment conditions.

Once it’s done, it will start deploying to your stage.
With Pre-Deployment gates, you not only have option to check ‘SonarCloud Quality’ status, but also it lets you choose other options like checking if your deployment Azure Policies are met and compliant and also many more like invoking a custom azure function you can code, check for alerts, etc. You can see the other options in the below screenshot.

In this blog post, we have learnt about what Pre-deployment gates are and how to integrate SonarCloud quality checks in your release pipeline.

I hope you enjoyed reading this post.

Happy Learning!!

DevSecOps with Azure DevOps

Vivekanand Rapaka — Wed, 28 Oct 2020 19:07:26 +0000

Purpose of this post

The purpose of this blog post is to give you high level overview on what DevSecOps is and some steps on how security can be integrated in your Azure DevOps pipeline with help of some readily available tasks in Azure DevOps related to some commonly used security scanning tools in build and release pipelines.

Continuous Integration, Deployment and Delivery

If you are reading this article, I’m assuming that you must have encountered these terms – CI and CD by and you do have a fair understanding of them.

Let’s recap on what we mean by each of these terms.

Continuous integration

Continuous integration is a process of automating the build and testing the quality of the code when someone in the team commits the code to your source control. This ensures that a particular set of unit tests are run, build compiles successfully, without any issues. In case, if the build fails, the person committing the code should be notified to fix the issues encountered. This is one of the software engineering practices where the feedback on the newly developed code is provided to the developers immediately, with different types of tests.

Continuous Delivery Vs Deployment

Both Continuous Delivery and Deployment are interesting terms. In Continuous Delivery, once the CI is done and the code is integrated in your source code, the ability to deploy the code automatically to various stages of the pipeline seamlessly and making sure that the code is production ready is Continuous Delivery, However in continuous delivery, the code is not deployed to production automatically. A manual intervention is required.

Where as in continuous deployment, Every build or change that is integrated passes all the quality checks, deployment gates and they get deployed from lower environments till Production automatically without any human intervention.

CI & CD helps you deliver the code faster, great!!!

but how about security?

DevSecOps is no longer a buzz word, or maybe it still is, but lot of organizations are shifting gears towards implementing the notion of including security in their Software Development lifecycle.

What is DevSecOps?

Security needs to shift from an afterthought to being evaluated at every step of the process. Securing applications is a continuous process that encompasses secure infrastructure, designing an architecture with layered security, continuous security validation, and monitoring for attacks.

In simple terms, the key focus around DevSecOps is that you need to make sure that the product you are developing is secure right from the time you start coding it and that the best practices of ensuring that security are met at every stage of your pipeline and an ongoing practice. In other words, security should be met as one of the key elements from the initial phase of development cycle, rather than looking at the security aspects at the end of the product sign-off/deployment. This is also called as ‘shift-left’ strategy of security. It’s more of injecting security in your pipeline at each stage.

How do can we achieve security at various stages of the pipeline?

There are multiple stages involved in getting your code deployed to your servers/cloud hosted solutions right from the developers coding it from the pipeline till deploying them.

Let’s now see few of them and how we can achieve integrating security around our pipelines using this.

Precommit–Hooks/IDE Plugins:

Precommit hooks/IDE Plugins are usually used to find and remediate issues quickly in the code even before a developer commits the code to the remote repository. Some of the common issues that can be found or eliminated are credentials exposed in code like SQL connection strings, AWS Secret keys, Azure storage account keys, API Keys, etc. When these are found in the early stage of the development cycle, it helps in preventing accidental damage.
There are multiple tools/plugins which are available and can be integrated in a developer’s IDE. A developer still get around these and commit the code bypassing these Precommit hooks. These are just the first line of defense but not meant to be your full-fledged solution for identifying major security vulnerabilities. Some of the Precommit hooks tools include – Git-Secret, Talisman. Some of the IDE plugins include .NET Security Guard, 42Cruch, etc. You can find more about other tools here:

https://owasp.org/www-community/Source_Code_Analysis_Tools

Secrets Management:

Using secret management for entire code base is one of the best practices. There could be a secret management tool that you can use like an Azure Key Vault, AWS secret manager, HashiCorp vault built into your pipeline already for accessing the secure credentials. The same secret management has to be used by your entire code base and not just the DevOps pipelines.

Software Composition Analysis:

As the name indicates, SCA is all about analyzing the software/code for determining the vulnerable open-source components, third party libraries that your code is dependent on.

In majority of the cases of software development, very less portion of code is written and rest of it is imported/dependent on from external libraries.

SCA focuses on not only determining the vulnerable open source components, but also shows you if there are any outdated components are present in your repo & also highlights issues with opensource licensing. WhiteSource bolt is one of the light weight tools that does scanning of the code integrates with Azure DevOps and shares the vulnerabilities and fixes in a report.

SAST (Static analysis security testing):

While SCA is focused on determining issues related to open source/third party components used in our code, it doesn’t actually analyze the code that is written by us.
This will be done by SAST. Some common issues that can be found are like SQL Injection, Cross-site scripting, insecure libraries, etc. Using these tools needs collaboration with security personnel as the initial reports generated by these reports can be quite intimidating and you may encounter certain false-positives. CheckMarx is one of the SAST tools.

DAST (Dynamic Analysis Security Testing):

Key differences between SAST and DAST is that while vulnerabilities can be determined in the third libraries in our code, it doesn’t actually scan the deployed site itself. There could be some more vulnerabilities which can’t be determined until the application is deployed into one of the lower environments like PreProd by providing target site URL. You can run DAST in a passive or aggressive mode. While passive test runs fairly quick, aggressive tests run for more time.

In general, a manual Pen test/DAST can take longer time. This will be done by a Pentester from security team. A manual test can’t be done every time you check-in the code or deploy the code as pen testing itself would take some amount of time.

I have worked on cloud migrations to Azure & AWS and we usually raise a request for DAST & Pentest test to security team at the last leg of migration lifecycle and get a sign-off from security team after all the identified vulnerabilities are fixed. Usually security team the takes a week or sometimes more than a week for them to complete the report, they run scripts, test data, try to break the application and what not to see if the application we migrated is secure enough. Once the vulnerability report is out, we look at the critical & high issues reported and start working on fixing them. Majority of the times, the deliverable timelines used to get extended based on the amount of work we had to do to remediate the issues raised. With DAST testing using ZAP Auto Scanner task in Azure DevOps, we can identify and fix the issues even before they become a bottle neck later.

And, security just doesn’t mean DAST/ Pentest or code quality alone. The infrastructure you deploy should also be secure. With your environment deployed on Azure, you have Azure Polices/Initiatives that help you govern and put rail guards around your infrastructure by auditing & enforcing the rules you specify. You could enforce polices to make sure that your infrastructure meets your desired state. For example, using Azure Polices, you can enforce use of managed azure disks only, storage accounts are not publicly accessible, Subnets in a particular VNet doesn’t allow Inbound Internet Traffic, SQL Server firewalls doesn’t allow internet traffic, etc. These are just of few of the tasks that you can achieve using Azure Polices. We will take a look at how Azure polices work in another blog post and also enabling effective monitoring and alerting is another key aspect.

Azure DevOps supports integration of multiple open source and licensed tools for scanning your application as a part of your CI & CD process.

In this blog post, we’ll see how to achieve security in our Azure DevOps pipeline using following tools:

WhiteSource Bolt extension for Scanning Vulnerability for SCA
Sonarcloud for code quality testing
OWASP ZAP Scanner for passive DAST testing

Sonarcloud for code quality testing:

1.WhiteSource Bolt:

Integrating WhiteSource bolt in your pipeline is pretty straight forward. In this blog post, I’m going to use one of the previous repos that I have used in my previous blog posts.

If you would like to follow along, feel free to clone/import it to your Azure DevOps repo and steps are in the previous blog post too.

To install WhiteSource Bolt in your Azure DevOps pipeline, search for “WhiteSource Bolt” from Marketplace and install it. You’ll go through a series of steps to get it installed in your organization.

It’s all straight forward.

I’m jumping straight ahead to the build pipelines, in which we are going to integrate WhiteSource Bolt.

Login to your Azure DevOps and click on Pipelines -> Build Pipelines and edit your build pipeline, you can import the complete project and pipelines from my git repo and the steps are mentioned my previous blog post. please refer to the link above.

Once in the build pipeline, to add the tasks click on “+” icon and search for “WhiteSource bolt” in Marketplace.

Back in your build pipeline, click “+” and add “WhiteSource Bolt” task

Leave the default settings as by default, it would scan your root directory.

Save and kick-off a new build.

In your build pipeline, you can see the logs of the task

In your build pipeline section, you will see that you have a new section for WhiteSource Bolt, you can click on this to view the results after the build pipeline completes the build.

You can also see the results in the build pipeline results and the report tab.

Notice that it not only shows the vulnerabilities, but also shows the fixes for each of them. Note that this has only scanned the third party libraries and open source components in the code but not the deployed code on the target infrastructure.

This can be achieved via DAST testing in release pipeline using ZAP Auto Scanner. We’ll see that as well in this blog post.

2.Sonarcloud

Now, let us see how to integrate SonarCloud in Azure DevOps Pipeline. Prior to adding task in Azure DevOps, we need to import our Azure DevOps Project in SonarCloud.

You need Sonarcloud account for integrating it in the pipeline. Login to https://sonarcloud.io/ with your Azure DevOps account and choose your organization.

Select import projects from Azure.

Create a personal access token in Azure DevOps, copy the token and paste it somewhere, we need it later

Back in Sonarcloud site, provide the personal access token to import the projects, choose defaults to continue.

Generate a token in Sonarcloud that will be used in Azure DevOps. Once logged in SonarCloud, go to My Account > Security > Generate Tokens and copy the token and paste it somewhere, we need it later.

Select the application project Click on ‘Administration’ -> ‘Update Key’ to find the key for the project.

Now back in Azure DevOps we need to add SonarCloud tasks. Go to the build pipeline and install SonarCloud plugin from marketplace. Just like WhiteSource bolt, search for Sonarcloud and install it in our Azure DevOps Organization.

Unlike WhiteSource bolt, we need to add three tasks for analyzing the code with SonarCloud.

Note that the project I’m trying to analyze is .NET Core, but the process of including the steps doesn’t vary much for any of the other technologies.

Add the ‘Prepare analysis on SonarCloud’ task before Build task.

Provide following details for the task:

SonarCloud Service Endpoint: Create a new service endpoint by clicking on ‘new’ and copy paste the code generated, give a name for Service connection name, Save and verify
Select the organization
Add Project key generated from SonarCloud earlier.

Below screenshot shows how to add a new service connection after clicking on ‘new’ in step 1.

Add ‘Run code Analysis’ and ‘Publish Quality Gate Result’ tasks and save it and create a build.

Publish Quality Gate Result task is optional, but it can be added to publish the report link and quality gate result status to the pipeline.

Save and initiate a build. Once you run it, you should see the logs as below:

In the build summary, under extensions tab, you can see the link to view the results.

In the above screen, the quality gate status shows as none. the reason for that is, in Sonarcloud Initial status for quality gate shows as “Not computed” for the project we imported.

To fix it, under administration tab, choose "Previous Version" and notice that it says that 'changes will take effect after the next analysis'.

Now, the status in overview shows that “Next scan will generate a Quality Gate”

Back in Azure DevOps, trigger another build and wait for it to complete.

Now under extensions tab of build summary, it should show the result status along with the link to view the Bugs, Vulnerabilities, etc. click on the "Detailed SonarCloud Report" to view the results.

The beauty of Sonarcloud is that you can integrate in your branch polices for any new Pull Requests raised and also as one of the deployment gates for deploying the bug free code to your environments.

3. ZAP Auto Scanner:

One tool to consider for penetration testing is OWASP ZAP. OWASP is a worldwide not-for-profit organization dedicated to helping improve the quality of software. ZAP is a free penetration testing tool for beginners to professionals. ZAP includes an API and a weekly docker container image that can be integrated into your deployment process.

Definition credits: owasp.org

With ZAP scanner you can either run a passive or active test. During a passive test, the target site is not manipulated to expose additional vulnerabilities. These usually run pretty fast and are a good candidate for CI process. When the an active san is done, it is used to simulate many techniques that hackers commonly use to attach websites.

In your release pipeline, click on add to add a new stage after PreProd stage.

Create a new stage with ‘Empty Job’.

Rename it to DAST Testing.

Click on add tasks and add get ‘ZAP Auto Scanner’ task from market place.

Once done, add following tasks one after the other.

OWASP Zap Scanner:

Leave Aggressive mode unchecked.
Failure threshold to 1500 or greater. This to make sure that the test doesn’t fail if your site has score more in number. Default is 50.
Root URL to begin crawling: Provide your URL that the scan needs to run against.

Word of Caution: Don't provide any site URLs in the above step that you don't own. crawling against sites that you don't own is considered as hacking.

4.Port: default is 80, if your site is running on secure port, provide 443, else you can leave it to port 80

Nunit template task: this is mainly used to install a template that is used by Zap scanner to produce a report.

The in-line script used is present in description of the tool in Azure Market Place.

https://marketplace.visualstudio.com/items?itemName=CSE-DevOps.zap-scanner

Generate nunit type file task: This used to publish the test results in XML format to owaspzap directory in the default working directory.

Publish Test Results task: this is mainly used to publish the test results from the previous task.

Make sure that you select the agent pool as ‘ubuntu-18.04’

Once everything is done, Kick off a release. Make sure that Preprod stage is deployed and the environment is ready before running DAST testing stage.

Once a release is complete, you should be able to see the results in the tests tab of the release you created.

With this, We have seen how to integrate security testing using WhiteSource Bolt, SonarCloud and OWASP ZAP Scanner in our DevOps pipeline at various stages of build and release.

This brings us to the end of this blog post.

Just like DevOps, DevSecOps also needs cultural shift. It needs collaboration from all departments of an organization to achieve security at each level.

Hope you enjoyed reading it. Happy Learning!!

Couple of references I used for writing this blog post:

https://www.youtube.com/watch?v=DzX9Vi_UQ8o&t=724s

https://docs.microsoft.com/en-us/azure/devops/migrate/security-validation-cicd-pipeline?view=azure-devops

Terraform and Azure DevOps

Vivekanand Rapaka — Tue, 20 Oct 2020 13:14:26 +0000

Purpose of this article

The main purpose of this article is to show you how to deploy your infrastructure using Terraform on Azure DevOps and deploy a sample application on multiple environments.

I've been working on terraform for a while now and as a part of my learning process, thought I should write a blog post to show how to work with terraform on Azure DevOps and deploy an application into multiple environments.

In this post, we'll spin up our infrastructure on Azure by setting up the build & release pipelines and We'll also take a look at what each of the tasks in the build & release pipelines does.

Things you need to follow along

If you would like to do this on your own, following are the prerequisites you need:

Azure Subscription
Azure DevOps Account

Assumptions

This blog assumes that you have fair understanding of Azure, Azure DevOps & Terraform. Initially, we'll go through the setup required and then I'll discuss in detail about each of the pipeline steps.

Ok, lets dive right in.

As you may have already known, terraform is one of the infrastructure as code tools that enables us to deploy your landing zones in your respective cloud environments like Azure, AWS, GCP, soon.

Terraform is considered as one of the tools in DevOps toolset.

So, we’ll take a look at how we can deploy our landing zone to different environments using Azure DevOps and deploy a sample application to it.

I’ve taken a Microsoft’s demo application PartsUnlimted and added my terraform code to it.

It also contains the build and release pipeline json files you can import to follow along and replicate the same in your own subscription.

Here are the steps that we’ll do as a part of this our implementation:

Import the code from my github repo to Azure DevOps
Setup build pipeline
Setup release pipeline
Access the application in Dev
Deploy the application to PreProd, Prod
Walk-Through of terraform code, tasks in build & release pipelines

Code import from GitHub & Project Setup

Click on ‘Repos’ -> files and import the code. Click on the 3rd option, import

Copy/Paste the following URL in clone URL https://github.com/vivek345388/PartsUnlimited.git and click on import

Once it’s done, it will show that the code is now imported and you will be able to see the repo with code.

In the above folder,

Infra.Setup folder contains the terraform files that we will be using to deploy our infrastructure.
Pipeline.Setup folder contains the build &release pipelines json files. Download both the json files from Build Pipeline & Release Pipeline to your local folder

Repeat the same step to download release pipeline json file from the code ReleasePipeline->PartsUnlimitedE2E_Release.json as well to your local folder.

Build Pipeline Setup

Now, let’s setup the build pipeline. Click on pipelines -> pipelines

Click on ‘Import Pipeline’

Click on browse and select the downloaded build Json file.

Once import is successful, you will see below screen where it says some settings needs to attention

For the agent pool, Choose ’Azure Pipelines’

In the agent specification, choose ‘vs2017-win2016’

Click on ‘Save & queue’ to queue a new build.

Choose the defaults and click on ‘save and run’

Once its complete, you should be able to see the pipeline run and its results.

We can also see the published artifacts in the results.

Now this completes the build pipeline setup. Let’s also configure release pipeline.

Release Pipeline Configuration

Click on ‘releases’ and click on 'New pipeline'

Quick Note: At the time of writing this article, we don't have an option to import an existing pipeline from new release pipeline page when you don't have any release pipelines. Hence we have to create a new empty pipeline to get to the screen where we can import the downloaded release pipeline json file.

Choose ‘empty job’ and click on ‘save’

Now, come back to the releases page and click on the releases one more time and choose import pipeline.

Choose release pipeline json that’s downloaded in the beginning.

It would look like below after the pipeline has been imported. Click on ‘Dev’ of the stage to configure the settings.

Quick note: You need to have following tasks installed from Azure Market Place. if you don't have them in your subscription, please get them from here.

Replace tokens

Terraform

Click on ‘Azure cli’ & ‘App service deploy’ tasks and choose the subscription to authorize.

Quick Note: I’m not using service principals/connections here to keep it simple for the purpose of this blog post.

Repeat the same steps for rest of the stages ‘PreProd’ & ‘Prod’. Once you complete all the tasks that needs attention, click on save at the top of the screen to save the pipeline.
Here is how the pipeline should look like after you complete everything.

After you have saved everything, click on ‘Create release’ in above screen.

Click on ‘logs’ option to view the logs for each of the tasks.

After successful deployment to Dev, it would look like this.

Once everything is done, you would see that code is deployed successfully to dev and you can browse the page by accessing the webapp link.

Go to your Azure portal and grab your webapp link and access it.

Back in your Azure DevOps release pipeline, As continuous deployment is enabled, it deploys the code to all the environments one after the other once the deployment is successful.

Now let’s take a minute to examine what each of the files in our Infra.Setup folder does.

I’ve used the concept of modules in terraform to isolate each of the components we are deploying. This is similar to linked templates in ARM templates.

Every terraform file that we author is considered as a module.

In a simple Terraform configuration with only one root module, we create a flat set of resources and use Terraform' s expression syntax to describe the relationships between these resources:

resource "azurerm_app_service_plan" "serviceplan" {
  name                = var.spName
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name

  sku {
    tier = var.spTier
    size = var.spSKU
  }
}

resource "azurerm_app_service" "webapp" {
  name                = var.webappName
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  app_service_plan_id = azurerm_app_service_plan.serviceplan.id
}
```




In the above code block, we declare two resources, app service and service plan in a single file. Later, app service is referencing the app service plan in the same file. while this approach is fine for smaller deployments, when the infrastructure grows, it would be challenging to maintain these files.

When we introduce module blocks, our configuration becomes hierarchical rather than flat: each module contains its own set of resources, and possibly its own child modules, which can potentially create a deep, complex tree of resource configurations.

However, in most cases terraform strongly recommend keeping the module tree flat, with only one level of child modules, and use a technique similar to the above of using expressions to describe the relationships between the modules.




```

module "appServicePlan" {
    source  = "./modules/appServicePlan"
    spName  = var.spName
    region  = var.region
    rgName  = var.rgName
    spTier  = var.spTier
    spSKU   = var.spSKU
}

module "webApp" {
    source         = "./modules/webApp"
    name           = var.webAppName
    rgName         = var.rgName
    location       = var.region
    spId           = module.appServicePlan.SPID
    appinsightskey = module.appInsights.instrumentation_key
}
```



Here you can see that both app service plan and app service are called as modules by main.tf file

> Definition Credits: Terraform.io

#### Benefits of modular based templates

Modules or Linked Templates yields us following benefits:
1.  You can reuse the individual components for other deployments.
2.  For small to medium solutions, a single template is easier to understand and maintain. You can see all the resources and values in a single file. For advanced scenarios, linked templates enable you to break down the solution into targeted components.
3.  You can easily add new resources in a new template and call them via main template.

Following are the resources that we deployed as a part of this blog post.

1.  App service plan – To host the Webapp
2.  App Service – Webapp to host the application.
3.  Application insights – To enable monitoring.

Its hierarchy looks like this.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/nrwruxhd501rsgfy2byb.png)

In general when we have a single file for deployments, we pass the variables in the same file or use a .tfvars file to pass the variables.

> Variables are same as Parameters in ARM templates

 In the above file structure, each individual template for example: webapp.tf will have its variables that it needs. The values have to be passed to it when this module is called. Remember that each terraform file that we create is considered as a module.



```
variable "name" {}
variable "location" {}
variable "rgName" {}
variable "spId" {}
variable "appinsightskey" {}

resource "azurerm_app_service" "webApp" {
  name                = var.name
  location            = var.location
  resource_group_name = var.rgName
  app_service_plan_id = var.spId
  app_settings = {
    "APPINSIGHTS_INSTRUMENTATIONKEY" = var.appinsightskey
  }
}

resource "azurerm_app_service_slot" "webApp" {
  name                = "staging"
  app_service_name    = azurerm_app_service.webApp.name
  location            = azurerm_app_service.webApp.location
  resource_group_name = azurerm_app_service.webApp.resource_group_name
  app_service_plan_id = azurerm_app_service.webApp.app_service_plan_id

  app_settings = {
    "APPINSIGHTS_INSTRUMENTATIONKEY" = var.appinsightskey
  }

}
```


Now lets see how the values are passed and modules are called in individual templates.

There are two main files that control the entire deployment.

1.  main.tf     -  Contains the code to call all the individual resources.
2.  main.tfvars -  Contains variables that are consumed by main.tf file

in the main.tf file, each of the modules will be called as follows:



```
module "appServicePlan" {
    source  = "./modules/appServicePlan"
    spName  = var.spName
    region  = var.region
    rgName  = var.rgName
    spTier  = var.spTier
    spSKU   = var.spSKU
}

module "webApp" {
    source         = "./modules/webApp"
    name           = var.webAppName
    rgName         = var.rgName
    location       = var.region
    spId           = module.appServicePlan.SPID
    appinsightskey = module.appInsights.instrumentation_key
}
```



the variables are declared in the same file in the variables section.




```
variable "region" {}
variable "rgName" {}
variable "spName" {}
variable "spTier" {}
variable "spSKU" {}
variable "webAppName" {}
variable "appInsightsname" {}
variable "AIlocation" {}
```


The values for above variables will be passed from main.tfvars file.

We use the same templates for deployment to all the environments. so how does Azure DevOps handles deployments to different environments? 

We keep place holders `#{placeholdername}#` for each of these values passed in our main.tfvars file.



```
region = #{region}#               
rgName = #{ResouceGroupName}#       
spName = #{spName}#                     
spSKU =  #{spSKU}#                
spTier = #{spTier}#             
webAppName = #{webAppName}#         
appInsightsname = #{appInsightsname}#   
AIlocation = #{AIlocation}#
```



when use the same templates for deploying to multiple environments, We use ‘replace tokens’ task in Azure DevOps and place respective values for each environment. This helps us in choosing different values for each environment. 

For example, the value for `#{webAppName}#` will be different per environment.

`app-dev-webapp` for dev
`app-ppd-webapp` for preprod
`app-prd-webapp` for prod

While the main.tfvars file has a place holder `#{webAppName}#` for this, we declare the values for it in our variables section of release pipeline

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/le554ov6poum36z7wr2j.png)

The 'replace tokens' task has an option called token prefix where we can declare the token prefix and suffix for the place holder value in the file we would like to replace in. In the target files, we place the files would like to get targeted for this replacement. Here we gave  **/*.tf and **/*.tfvars as the target as these files have the placeholder content.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/zkye3l3pjt1jg0wgu7rw.png)


#### Build Pipeline

Build pipeline is mostly self explanatory as the first couple of tasks complie the application and publish the code.

Take a look at the Publish Artifact: Artifacts, Publish Artifact: Infra.Setup tasks

Publish Artifact: Artifacts : publishes the compiled code to Azure Pipelines for consumption by release pipelines

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/0lacldmqb5102w46hzmx.png)

Publish Artifact: Infra.Setup tasks : publishes the terraform templates to Azure Pipelines for consumption by release pipelines. As we dont need to compile them we can directly choose them from the repo as path to publish.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ux4yo5iyob2z0h7ve0bl.png)

At the end of the build pipeline, it would publish the artifacts as below:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/kmk5dxi8dorej29sg6uw.png)

These will be consumed in our release pipeline for deployment.

#### Release Pipeline

You can see that the source artifacts are from our build pipeline.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/kwql3dbchgnlvr42wip7.png)

Now lets take a look at each of the release tasks.

1.Create Resource Group and Storage Account: Creates a storage account for storing .tfstate file that terraform stores the configuration of our deployment.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/taee0wi6sdc567ccctpb.png)

2.Obtain access Key and assign to pipeline variable: Retrieves the storage account key and assigns it to a variable in Azure Pipelines.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/6vf9ap663kiimmhjb3sw.png)

3.Replace tokens in **/*.tf **/*.tfvars: 

Remember that we have kept place holders to replace the values per environment, this task is responsible for the same. Values for each of the place holders in main.tf file are in variables section of each stage.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ep0gcpj7u2j9pavvg7rm.png)

4.Install Terraform 0.13.4: Installs terraform on the release agent.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/znrgo65e68g6y722dl92.png)

5.Terraform: init : Initializes the terraform configuration and we also have specified the storageaccount resource group and the storage account for it to place the .tfstate file

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/qc5a0d7ua279686n0b3r.png)

6.Terraform: plan : Runs terraform deployment in dry-run mode

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/5gjddnn0rm8vfewuf9jg.png)

7.Terraform: apply -auto-approve: Applies the configuration based on the dry-run mode in step 6.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/rf3ryfg6m4u9toek2txh.png)

8.Retrieve Terraform Outputs: This task is mainly responsible for retrieving each of the outputs obtained after terraform apply is complete and they are being consumed by the 'App Service Deploy' task. In case of Azure, we have ARM Outputs task readily available for us, here we need to write a small script to get the outputs.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/yl5pixffowk28lz3m5bk.png)


9.Azure App Service Deploy: Deploys the application code into the webapp.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/92egtw93q92g31mfbfa0.png)

### Conclusion

This brings us to the end of the blog post.

Hope this helps you learn, practice and deploy your infrastructure using Terraform via Azure DevOps!!

Thanks for reading this blog post & Happy Learning..