DevOps - IFI Techsolutions https://devifitechwebsite.azurewebsites.net Microsoft Solution Partner Tue, 02 Dec 2025 07:12:27 +0000 en-US hourly 1 https://wordpress.org/?v=6.9 /wp-content/uploads/2025/10/cropped-ifi-new-logo-icon-32x32.png DevOps - IFI Techsolutions https://devifitechwebsite.azurewebsites.net 32 32 Secrets Store CSI driver in AKS https://devifitechwebsite.azurewebsites.net/blogs/secrets-store-csi-driver-in-aks/ https://devifitechwebsite.azurewebsites.net/blogs/secrets-store-csi-driver-in-aks/#respond Tue, 24 Dec 2024 09:54:58 +0000 https://ifi-prod-poc-2.azurewebsites.net/?p=14824 Author – Anurag Chauhan, Cloud Engineer What is Secrets Store CSI driver? The Secrets Store CSI Driver provides Kubernetes a service to mount multiple secrets, certs, and keys which are stored in enterprise-grade external secrets store in their pods as a volume Prerequisites Azure subscription Azure CLI 2.31.0 or later. How it works Similar to […]

The post Secrets Store CSI driver in AKS first appeared on IFI Techsolutions.

]]>
Author – Anurag Chauhan, Cloud Engineer

What is Secrets Store CSI driver?

The Secrets Store CSI Driver provides Kubernetes a service to mount multiple secrets, certs, and keys which are stored in enterprise-grade external secrets store in their pods as a volume

Prerequisites

  • Azure subscription
  • Azure CLI 2.31.0 or later.

How it works

Similar to Kubernetes secrets, on pod start and restart the Secrets Store CSI driver communicates with the provider using gRPC to retrieve the secret content from the an external Secrets Store specified in the SecretProviderClass custom resource. Then the volume is mounted in the pod as tmpfs and the secret contents in are written to the volume. On pod deletion, the corresponding volume is cleaned up and deleted.

Secrets Store CSI Driver

The Secrets Store CSI Driver is a daemonset that helps in facilitating the communication with every instance of Kubelet. Each driver pod has following containers: node-driver-registrar: It registers the CSI driver with Kubelet so that it knows on which unix domain socket to inform the CSI calls on. This sidecar container is provided by the Kubernetes CSI team. secrets-store: It implements the CSI Node service gRPC services which are described in the CSI specification. And it also performs mounting/unmounting the volume during creation and deletion of a pod.This component is maintained and developed in this repository. liveness-probe: It is responsible for monitoring the health of CSI driver and reports directly to Kubernetes. This enables Kubernetes to automatically detect the issues within driver and restart the pod to try and fix the issue. This sidecar container is provided by the Kubernetes CSI team.

Provider for the Secrets Store CSI Driver

  • Azure Provider
  • AWS Provider
  • GCP Provider
  • Vault Provider

Features

  • Mounts the secrets, keys, and certificates to a pod by using a CSI volume
  • Supports CSI inline volumes
  • Mounts multiple secrets store objects as a single volume
  • pod portability with the SecretProviderClass CRD
  • Supports Windows containers
  • Syncs with Kubernetes secrets
  • It supports auto rotation of mounted contents and and syn it to Kubernetes secrets

Create an AKS cluster along with Azure Key Vault Provider for the Secrets Store CSI Driver support

First, create an Azure resource groupfollowed by an AKS cluster with Azure Key Vault provider for Secrets Store CSI Driver functionality, use the az aks create command with the azure-keyvault-secrets-provider add-on.
  • az group create -n myResourceGroup -l eastus2
  • az aks create -n myAKSCluster -g myResourceGroup –enable-addons azure-keyvault-secrets-provider –enable-managed-identity
Ensure the Azure Key Vault Provider for the installation of Secrets Store CSI Driver
  • kubectl get pods -n kube-system -l ‘app in (secrets-store-csi-driver, secrets-store-provider-azure)’

Create or use an existing Azure key vault

In AKS cluster, we need to create an Azure key vault which will store the secret. But here we have to keep in mind that the key vault’s name should be globally unique and this Azure key vault can store keys, certifications, and secrets.
  • az keyvault create -n -g myResourceGroup -l eastus2
  • az keyvault secret set –vault-name -n ExampleSecret –value MyAKSExampleSecret

Provide with an identity to access the Azure key vault

The Secrets Store CSI Driver have two methods to access Azure key vault:
  • An Azure Active Directory pod identity
  • A user-assigned or system-assigned managed identity

Use pod identities

Azure Active Directory (Azure AD) pod-managed identities use AKS primitives to associate managed identities for the Azure identities and resources in Azure AD along with pods. Further these identities can be used to grant access to the Azure Key Vault Secrets Provider for Secrets Store CSI driver.
  1. A cluster identity is to be created, then permissions are to be assigned followed by a pod identity.

Create an identity

You have to have the applicable permissions (owner) in your subscription to create the identity.
  • az group create –name myIdentityResourceGroup –location eastus
  • export IDENTITY_RESOURCE_GROUP=”myIdentityResourceGroup”
  • export IDENTITY_NAME=”application-identity”
  • az identity create –resource-group ${IDENTITY_RESOURCE_GROUP} –name ${IDENTITY_NAME}
  • export IDENTITY_CLIENT_ID=”$(az identity show -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME} –query clientId -otsv)”
  • export IDENTITY_RESOURCE_ID=”$(az identity show -g ${IDENTITY_RESOURCE_GROUP} -n ${IDENTITY_NAME} –query id -otsv)”

Assign permissions for the managed identity

  • NODE_GROUP=$(az aks show -g myResourceGroup -n myAKSCluster –query nodeResourceGroup -o tsv)
  • NODES_RESOURCE_ID=$(az group show -n $NODE_GROUP -o tsv –query “id”)
  • az role assignment create –role “Virtual Machine Contributor” –assignee “$IDENTITY_CLIENT_ID” –scope $NODES_RESOURCE_ID

Create a pod identity

  • export POD_IDENTITY_NAME=”my-pod-identity”
  • export POD_IDENTITY_NAMESPACE=”my-app”
  • az aks pod-identity add –resource-group myResourceGroup –cluster-name myAKSCluster –namespace ${POD_IDENTITY_NAMESPACE} –name ${POD_IDENTITY_NAME} –identity-resource-id ${IDENTITY_RESOURCE_ID}
Assign permissions to the new identity to read your key vault and consider its contents through the subsequent commands: # set a policy to access keys in your key vault
  • az keyvault set-policy -n –key-permissions get –spn
# set a policy to access secrets in your key vault
  • az keyvault set-policy -n –secret-permissions get –spn
# set a policy to access certs in your key vault
  • az keyvault set-policy -n –certificate-permissions get –spn
Create a SecretProviderClass with the usage of the following YAML, the use of your own values for aadpodidbinding, tenantId, and the objects to retrieve out of your key vault:
  • kubectl apply -f secretproviderclass.yaml
Create a pod via the use of the following YAML
  • kubectl apply -f pod.yaml

Validate the secrets

## show secrets held in secrets-store
  • kubectl exec busybox-secrets-store-inline — ls /mnt/secrets-store/
## print a test secret ‘ExampleSecret’ held in secrets-store
  • kubectl exec busybox-secrets-store-inline — cat /mnt/secrets-store/ExampleSecret

Disable the Azure Key Vault Provider for Secrets Store CSI Driver on an existing AKS cluster

  • az aks disable-addons –addons azure-keyvault-secrets-provider -g myResourceGroup -n myAKSCluster
Existing workloads will have no issues, if the add-on is disabled and will not see any updates in the mounted secrets. The scale up event happens if the pod restarts or a new pod is created, the pod will fail to start because the driver is no longer running state.

The post Secrets Store CSI driver in AKS first appeared on IFI Techsolutions.

]]>
https://devifitechwebsite.azurewebsites.net/blogs/secrets-store-csi-driver-in-aks/feed/ 0
Bicep: Modern language for ARM Template? https://devifitechwebsite.azurewebsites.net/blogs/azure-bicep/ https://devifitechwebsite.azurewebsites.net/blogs/azure-bicep/#respond Thu, 02 Sep 2021 06:51:44 +0000 https://ifi-prod-poc-2.azurewebsites.net/?p=13662 Infrastructure as a Code Infrastructure as code is the process of automating your infrastructure (networks, virtual machines, load balancers, and connection topology) provisioning. It uses a descriptive coding language and versioning system that is like what is used for source code.Idempotenceis a principle of Infrastructure as Code. Azure provides native support for IaC via the […]

The post Bicep: Modern language for ARM Template? first appeared on IFI Techsolutions.

]]>
Infrastructure as a Code Infrastructure as code is the process of automating your infrastructure (networks, virtual machines, load balancers, and connection topology) provisioning. It uses a descriptive coding language and versioning system that is like what is used for source code.Idempotenceis a principle of Infrastructure as Code. Azure provides native support for IaC via the Azure Resource Manager. Teams can define declarative templates that specify the infrastructure required to deploy their solutions.

Azure Resource Manager template

Azure Resource Manager is aservice and ARM Templates are a type of Infrastructure as Code. ARM templates are files that represent Azure resources. You write them in a special JSON format. They define the objects you want, their types, names, and properties in a JSON file. The ARM template syntax contains functions and methods to perform complex operations. They allow you to define your Azure Infrastructure using code in a declarative way. Rather than sayinghowyou want things to be created (e.g., Azure CLI/PowerShell), you specifywhatyou want to be created. Azure then ‘makes it happen’.

Introduction to Azure Bicep

The bicep is a “Domain-Specific Language for deploying Azure resources declaratively”. Probably the easiest way to think of it is that it’s simply ARM templates with a much nicer syntax. Bicep code is transpile to ARM templates. It certainly achieves the (not difficult) goal of being less verbose and easier for a human to read and write than an ARM template. Bicep embraces modularity. You can create a Bicep file that defines your preferred way of configuring any resource (storage account, virtual machine). And then another Bicep template can include that definition, only needing to override parameters it wants to change. This means that over time, as you use Bicep more, you should find you can reuse pre-existing templates rather than needing to build everything up from scratch every time.

How to install Bicep tools

To create Bicep files, you need a good Bicep editor (I am using Visual Studio Code)
  • Visual Studio Code– If you don’t already have Visual Studio Code, install it.
Bicep extension for Visual Studio Code. Visual Studio Code with the Bicep extension provides language support and resource autocompletion. The extension helps you create and validate Bicep files. To install the extension, search for bicep inthe Extensions tab or in the Visual Studio marketplace. SelectInstall.

To verify you’ve installed the extension, open any file with the. bicep file extension. You should see the language model in the lower right corner change toBicep.

Let’s write our first Azure Bicep template

Parameters

Each parameter needs a name and type. A parameter can’t have the same name as a variable, resource, output, or other parameters in the same scope. By providing different values for parameters, you can reuse a Bicep file for different environments.

Allowed values

You can define allowed values for a parameter. You provide the allowed values in an array. The deployment fails during validation if a value is passed in for the parameter that isn’t one of the allowed values.

Length constraints

You can specify minimum and maximum lengths for string and array parameters. You can set one or both constraints. For strings, the length indicates the number of characters. For arrays, the length indicates the number of items in the array.

The following example declares a parameter that must have 5 characters.

< If we are not passing minimum length characters then it will throw the below error,

Default value

You can specify a default value for a parameter. The default value is used when a value isn’t provided during deployment. To specify a default value along with other properties for the parameter, use the following syntax.

You can use expressions with the default value. You can’t use thereferencefunction or any of thelistfunctions in the parameters section. These functions get the resource’s runtime state and can’t be executed before deployment when parameters are resolved.

Description

To help users understand the value to provide, add a description to the parameter. When deploying the template through the portal, the description’s text is automatically used as a tip for that parameter. Only add a description when the text provides more information than can be inferred from the parameter name.< To deploy a resource through a Bicep file, you add a resource declaration by using theresourcekeyword.

Set resource type and version

When adding a resource to your Bicep file, start by setting the resource type and API version. These values determine the other properties that are available for the resource. The following example shows how to set the resource type and API version for a storage account. The example doesn’t show the full resource declaration. You set a symbolic name for the resource. In the preceding example, the symbolic name ispip. You can use any value for the symbolic name, but it can’t be the same as another resource, parameter, or variable in the Bicep file. The symbolic name isn’t the same as the resource name. You use the symbolic name to reference the resource in other parts of your Bicep file.

Set resource name

Each resource has a name. When setting the resource name, pay attention to the rules and restrictions for resource names.

Set location

Many resources require a location. You can determine if the resource needs a location either through intelligence or template reference. The following example adds a location parameter.

Set resource-specific properties

The preceding properties are generic to most resource types. After setting those values, you need to set the properties that are specific to the resource type you’re deploying. Use intelligence or template referenceto determine which properties are available and which ones are required. The following example sets the remaining properties for a public IP address,

Define variable

When defining a variable, you don’t specify a data type for the variable. Instead, provide a value or template expression. The variable type is inferred from the resolved value. The following example sets a variable to a string.

String Interpolation

Bicep templates allow using string interpolation. You can define strings using a parameter or variable name, and Bicep will evaluate the final string using the actual values.

Define output values

The following example shows how to use the output keyword to return property from a deployed resource. In the following example,pipis the identifier (symbolic name) of a public IP address deployed in the Bicep file. The output value gets the fully qualified domain name for the public IP address.

Define modules

Every Bicep file can be consumed as a module. A module only exposes parameters and outputs as contracts to other Bicep files. Both parameters and outputs are optional. The following Bicep file can be deployed directly to create a storage account or be used as a module.

Reference

https://github.com/ashwini19101994/azurebicepVMcreation.git

Visualize resources

You can view a representation of the resources in your file. From the upper left corner, select the visualizer button to open the Bicep Visualizer. The visualizer shows the resources defined in the Bicep file with the resource dependency information.

Deploying Bicep Templates

Now that you have a Bicep template built, it is time to deploy! You have two options for deploying Bicep templates. You can deploy using the Bicep template or convert the template to ARM JSON for deployment. To deploy using the Azure CLI, use the az deployment group create command specifying the resource group name and template file. az deployment group create\ –resource-group AzureBicep-RG\ –template-file vmcode.bicep

Overview of resources from azure portal

Clean up resources

az group delete –name AzureBicep-RG Closing Note Yes! Azure Bicep is a modern language and taking place in the market with its simplicity.

The post Bicep: Modern language for ARM Template? first appeared on IFI Techsolutions.

]]>
https://devifitechwebsite.azurewebsites.net/blogs/azure-bicep/feed/ 0
SSO Configuration using SAML v2.0 and Azure Active Directory for Custom web application https://devifitechwebsite.azurewebsites.net/blogs/sso-configuration-saml-v2-0-and-azure-active-directory/ https://devifitechwebsite.azurewebsites.net/blogs/sso-configuration-saml-v2-0-and-azure-active-directory/#respond Thu, 08 Jul 2021 05:59:00 +0000 https://ifi-prod-poc-2.azurewebsites.net/?p=11763 Author: Ajinkya Bhabal, Cloud Engineer. Introduction What is SAML v2.0? It is an open standard for exchanging authentication and authorization data between an identity provider and a service provider. The best use cases will be building Single Sign-on for applications. Here we will deploy our web application in Azure virtual machine and Azure Active Directory […]

The post SSO Configuration using SAML v2.0 and Azure Active Directory for Custom web application first appeared on IFI Techsolutions.

]]>
Author: Ajinkya Bhabal, Cloud Engineer.

Introduction

What is SAML v2.0?

It is an open standard for exchanging authentication and authorization data between an identity provider and a service provider. The best use cases will be building Single Sign-on for applications.

Here we will deploy our web application in Azure virtual machine and Azure Active Directory will be used as identity management. As with the SAML v2.0 authentication mechanism, we can use the SSO feature on your custom web applications.

The best thing here Azure provides an application proxy feature where you can bring your on-premises application.

To test SAML authentication with a custom application, we can use SimpleSAMLPHP SAML Solution. It will be set as Service Provider and Azure AD will be Identity Provider.

What is SimpleSAMLPHP? SimpleSAMLPHP is an open-source PHP authentication application that provides support for SAML 2.0 as a Service Provider (SP) or Identity Provider (IdP).

Terminologies
  • (SSO) Single Sign-On: the simple concept of having one identity management service handle user logins for multiple websites.
  • (IDP) Identity Provider: the one identity service that stores usernames and passwords to handle log-ins.
  • (SP) Service Provider: Multiple websites uses the same IDP solution to manage user information.

Here is the workflow which you can refer to for understand how SAML works,

Implementation

Pre-requisites for SAML Setup in Azure AD
  1. A Microsoft Azure AD premium subscription
  2. User identities are created directly within your Azure AD tenants.
  3. To use the Application Proxy feature to set up SAML on your On-premises app, you need a Windows server running Windows Server 2012 R2 or later for installing the Application Proxy connector on the server. This connector server needs to connect to the Application Proxy services in Azure, and the on-premises applications that you plan to publish.
  4. If there’s a firewall in the path, make sure it’s open. An open firewall allows the connector to make HTTPS (TCP) requests to the Application Proxy.

Let’s, begin with the setup of the Application proxy to add our web application to Azure.

To get a better idea, you can refer to the below diagram.

As consideration for the on-premise environment, we will have two virtual machines, one has an application proxy connector agent is installed and one has the PHP-based web application is running.

Let’s start with a walkthrough of how we will implement this whole process.

Step 1: Here we will download the application connector agent on the same network in any other server machine.

Step 2:Here are some registries changes needed, just execute the below code.

Step 3:Just run the above registry file.

Step 4:After registry changes, you will get the successful output.

Step 5:Now we will start installing the application proxy connector agent.

Step 6:You need to sign in with the Global admin account to register this device.

Step 7: Here we can see the application proxy agent has been successfully installed.

Step 8:Now we will take a quick look at the Azure portal to check device is registered in the Application proxy plane.

Step 9:It’s time to create an enterprise application that will point to our SimpleSAML Web application. Behind the scenes, I have created a DNS entry of the IP address of SimpleSAMLPhp web app running server pointing to atlantis.ml. Which is basically I have created an A Record for the Web server.

Step 10:You need to download the tar file of the SimpleSAMLPhp solution on your web server.

Step 11:There are some configuration changes that need to be done for SAML Authentication to be worked. The first is to change the base URL to the /simplesaml/www which’s where the UI of the website resides in the config file.

Here /simplesaml is just folder name in WAMP Server which contains all the Application data that we have downloaded earlier.<

Step 12:Again, in the config file change the time zone according to your time zone.

Step 13:The admin password needs to be changed again in the config file, so with the help of the administrator account we can use its built-in tools.

Step 14:In our application, we will start with SAML configuration, where entity id is globally unique, and the reply URL is required so after verifying in Azure AD response will be sent to it.

Step 15:In the Authsources file we need to specify the entity ID that we have given earlier.

Step 16:Next identity provider identifier will be required.

Step 17:Here we have specified the identity provider identifier link.

Step 18:Now let’s try visiting our SAML solution web URL.

Step 19:Now we need to go to the authentication section, where we can log in as either Administrator or user in the APP.

Step 20:Now we will log in with an admin account.

Step 21:Here we will give credentials that we have set earlier in the config file.

Step 22:As with admin, we get access to a tool like XML to SImpleSAMLphp metadata converter. With this, we will set metadata for our application as provided in Azure AD Applications.

Step 23:Now we will download the federation metadata file from the Azure AD Application pane.

Step 24:Now we will upload that XML file here to get the required metadata.

Step 25:here is converted metadata that will be added in the SimpleSAMLPhp solution.

Step 26:In the saml20-IDP-remote.php file above metadata will get added,

Step 27:Here we have added users who can then access the application through Azure AD Authentication.

Step 28:Let’s again go to the authentication menu, and sign in as a user i.e., default-sp to test SAML Authentication.

Step 29:Here in the sign-in URL you can see the SAML request has been made by the Web application to the Azure Active directory for SAML 2.0 SSO authentication.

Step 30:After sign-in Azure AD gives a SAML response saying the user has valid permission to access an application. Now you can see the application data, which is available for authenticated users.

The post SSO Configuration using SAML v2.0 and Azure Active Directory for Custom web application first appeared on IFI Techsolutions.

]]>
https://devifitechwebsite.azurewebsites.net/blogs/sso-configuration-saml-v2-0-and-azure-active-directory/feed/ 0
WordPress CI/CD using Azure DevOps https://devifitechwebsite.azurewebsites.net/blogs/wordpress-ci-cd-azure-devops/ https://devifitechwebsite.azurewebsites.net/blogs/wordpress-ci-cd-azure-devops/#respond Thu, 21 Jan 2021 08:45:01 +0000 https://ifi-prod-poc-2.azurewebsites.net/?p=10293 Author- Anubhav Bisht (Cloud Engineer) Continuous integration (CI) and continuous deployment (CD) form a pipeline by which you can build, release, and deploy your code. Azure DevOps Services provides a complete, fully featured set of CI/CD automation tools for deployment to Azure. WordPress (WP, WordPress.org) is a free and open-source content management system (CMS) written […]

The post WordPress CI/CD using Azure DevOps first appeared on IFI Techsolutions.

]]>

Author- Anubhav Bisht (Cloud Engineer)

Continuous integration (CI) and continuous deployment (CD) form a pipeline by which you can build, release, and deploy your code. Azure DevOps Services provides a complete, fully featured set of CI/CD automation tools for deployment to Azure. WordPress (WP, WordPress.org) is a free and open-source content management system (CMS) written in PHP and paired with a MySQL or MariaDB database.

This post describes how to setup a CI/CD pipeline using Azure DevOps for deploying a containerized custom WordPress website working with Azure WebApp for Containers and Azure Database for MySQL.

Prerequisites:

  • An Azure account with following services:
    • An instance of Azure Container Registry.
    • An instance of Azure Database for MySQL with an empty database.
    • An instances of Azure WebApp for Containers.
  • An Azure DevOps account for performing CI/CD.

Code Structure:

You can find the Sample Code here, create a new project in Azure DevOps and import the code there.

  • HTML Directory:contains the WordPress structured files and directories like wp-config.php, wp-content, etc.
  • Dockerfile: contains the commands for building the containerized image:
[dt_code] FROMwordpress:4.9.1-apache COPYhtml/var/www/html RUNchown-Rwww-data:www-data/var/www/html/ ENTRYPOINT[“apache2-foreground”] [/dt_code]  

Building Project Pipeline:

  1. Continuous Integration:
    • Create a new project in Azure DevOps
    • In the Repos section, select Importto import the repository from Github
    • Now ,in the Pipelines section, create a new pipeline and select your repository that has the code
    • Search and select the Docker Containerjob to build and push the image to Azure Container Registry
    • Select the Azure Pool and Agent Specification according to the requirement, and in the two tasks add the information accordingly
    • In the Triggers,enable Continuous Integration and Save & Queue the pipeline
    • Once the job is completed, the different steps involved in it can be seen in the logs and the build image in the Azure Container Registry

So, after the successful building and pushing of the containerized image to the Azure Container Registry, our Continuous integration part is competed. Now, let’s move on for the Continuous Deployment.

 

2. Continuous Deployment:

    • In Azure DevOps, go to thePipeline section and selectReleaseand create a New Pipeline
    • SelectAzure App Service Deployment as the CD job
    • Select the Artifact source as Azure Container Registry and select the registry and repository
    • Select the Agent Pool and Agent Specifications according to requirements and configure the remaining task accordingly
    • Enable Continuous Deployment trigger, save the pipeline and select Create Release to run it
    • After completion of the Release pipeline, we can view the logs details of steps involved in the pipeline
 

Installing WordPress:

  • Go to the app service in Azure Portal which has wordpress deployed in it and click onBrowse
  • Now we can install WordPress
 

For every update that is pushed to the Repo in Azure DevOps, a Continuous Integration will be triggered followed by Continuous Deployment of the Containerized Image to the Azure Container Registry and App Service.

Ready to get started?

As a Microsoft partner with expertise in application migration and modernization, we’re ready to help you move your apps to the cloud.

The post WordPress CI/CD using Azure DevOps first appeared on IFI Techsolutions.

]]>
https://devifitechwebsite.azurewebsites.net/blogs/wordpress-ci-cd-azure-devops/feed/ 0