DEV Community: Roman Kiprin

Code review with private LLM? In pipeline? Simple!

Roman Kiprin — Tue, 16 Dec 2025 02:57:46 +0000

When you push code to GitLab and plan to merge it into the main branch, having your changes reviewed is essential. This review process helps ensure that you don't introduce poorly written code or create new security vulnerabilities.

Imagine receiving immediate code analysis that provides valuable insights into your code quality and potential issues and looks like this:

### Safety Index: 6/10

The code changes introduce significant functionality improvements but also present several areas of concern that affect maintainability and potential security.

### Detailed Suggestions

**1: Memory leak risk in conversation history management in app/main.py lines 44-69. The in-memor

.....

Moreover, this solution is cost-effective and compatible with various technologies. Rather than utilizing third-party LLM services that may train their models on your data, you can deploy your own private Large Language Model.

While this may seem challenging, such solutions are not only feasible in today's AI landscape, but are also remarkably affordable. I'll demonstrate how this can be accomplished.

GitLab for code, Azure for LLM, opencode for managing code review

Allow me to introduce the infrastructure.

GitLab.com - the project holder and manages repository and pipelines.
opencode - one of the best (and the most 'open') agentic command line code generation utility.
Microsoft Foundry - SaaS/PaaS solution to privately run LLMs and perform a lot of other stuff.

Project to gather all together. It is an LLM chat app, of course.

To demonstrate the setup in a near-production environment, I developed an AI-driven application. This application serves primarily as a sandbox for testing various technologies, with no intended practical use beyond that purpose.

You can find the application at: chat.roki.cool. Please note that hosting costs approximately $30 per month, so it may be unavailable at the time you're viewing it.

Don't worry! While the application is entertaining, it's not the main focus of this article.

The schema

Below is the diagram of the complete project. However, this article focuses specifically on the portion related to implementing LLMs in GitLab pipelines.

Therefore, we'll be examining only the relevant section of the diagram, which is clear.

Let me start with the model, OK?

The gpt-oss-120b large language model

Why gpt-oss-120b? To be honest, you can chose whatever LLM you like from the list that Microsoft provides you with. There is a huge variety. Models by OpenAi. Best models, provided by partners, like DeepSeek, Grok, Kimi, ollama...

And more partners, like (arguably the best models) from Anthropic: claude sonnet, claude opus (including 4.5!) and more! If that is not enough - you can deploy models from huggingface! However, I did not try that.

For this implementation, I chose gpt-oss-120b primarily because of its cost-effectiveness. It is about 10-30 times cheaper than leading models from premium vendors.

While I wouldn't recommend gpt-oss-120b for code generation tasks, it excels at code analysis, making it an ideal choice for this specific use case. The decision was straightforward given these considerations.

By any means, if you are interested in investing more, you are welcome - the technology stays the same.

Microsoft Foundry

To be honest, Microsoft Foundry is huge. Just look at its documentation. And Microsoft tries to bring consistency with that "new" look and feel.

For our purposes, we'll be using it simply as a hosting environment to run our preferred LLMs. This is similar to how you might use your own local machine with substantial resources - though most of us don't have access to 196GB of memory and multiple GPUs at home, which is exactly why services like Microsoft Foundry are valuable.

To run workloads on Microsoft Foundry, you'll need a standard Azure subscription. Here's what you'll need to set up:

Create the Foundry service

Create a Foundry project within Foundry service

Open Foundry portal and have full control over the Foundry provided services

Have your LLM endpoint and secret via Foundry home

or via Azure Portal interface:

... and you are good to go. OK, almost good to go. Let me save you a couple of hours on your research.

The LLM endpoint and secret

That is, probably, the trickiest part of the story. Microsoft provides different endpoints for various LLMs, and you'll need to locate the specific URI for your chosen model:

However, I found that opencode does not work with this endpoint. (At least I failed to make it working.) So, I did my testing and discovered, that

most of the models are available via different endpoints simultaneously
opencode works with any "openai-compatible" endpoint

That means your LLM endpoint should look like this:

https://<name_of_your_ms_foundry_service>.services.ai.azure.com/models

So, you have to setup LLM_ENDPOINT and LLM_KEY as CI/CD variables in your project:

We will use them in the GitLab pipeline later on!

The GitLab pipeline

Not really. The entire pipeline definition is available in my gitlab repository.

Here I will show you only the job, related to the opencode setup and execution.


validate_job:
  stage: validate
  image: node:22-slim
  script:
    - echo "Installing opencode"
    - npm install --global opencode-ai
    - echo "Installing glab"
    - export GITLAB_TOKEN=$GITLAB_TOKEN_OPENCODE
    - apt-get update --quiet && apt-get install --yes curl wget gpg git && rm --recursive --force /var/lib/apt/lists/*
    - curl --silent --show-error --location "https://raw.githubusercontent.com/upciti/wakemeops/main/assets/install_repository" | bash
    - apt-get install --yes glab jq
    - echo "Configuring glab"
    - git config --global user.email "opencode@gitlab.com"
    - git config --global user.name "Opencode"
    - GITLAB_HOST=https://gitlab.com
    - GITLAB_TOKEN=$CI_JOB_TOKEN
    - echo $GITLAB_HOST
    - echo "Creating opencode auth configuration"
    - mkdir --parents ~/.local/share/opencode
    - |
      cat > ~/.local/share/opencode/opencode.json << EOF
      {
        "$schema": "https://opencode.ai/config.json",
        "model": "back/gpt-oss-120b",
        "provider": {
          "back": {
            "npm": "@ai-sdk/openai-compatible",
            "options": {
              "baseURL": "$LLM_ENDPOINT",
              "apiKey": "$LLM_KEY"
            },
            "models": {
              "gpt-oss-120b": {
                "name": "gpt-oss-120b",
                "tool_call": true,
                "reasoning": true,
                "limit": {
                  "context": 128000,
                  "output": 128000
                },
                "options": {
                  "tools": true,
                  "reasoning": true
                }
              }
            }
          }
        }
      }
      EOF
    - echo "Running Opencode"
    - opencode -version
    - PROMPT1=$(cat ./gitlab-ci.prompt1.md)
    - echo -e "\n \n"
    - opencode run "$PROMPT1"
    - CURRENT_SAFETY_SCORE=$(cat ./smell_analysis.json | jq .safety_score)
    - echo "Safety score $CURRENT_SAFETY_SCORE. It is supposed to be better than $SAFETY_SCORE to continute."
    - |
      if [ $CURRENT_SAFETY_SCORE -le $SAFETY_SCORE ]; then
         echo -e "The safety score of the changes is lower than our standards allow. This is a blocker. \n \n \033[31mYou shall not pass!!!\033[0m  \n \n"
         exit 1
      fi

I'll outline and explain each component of this process.

First, we install opencode into a Docker image and set up the default Git configuration. This enables the LLM that opencode communicates with to access the Git repository, should the AI determine it's necessary.

    - echo "Installing opencode"
    - npm install --global opencode-ai
    - echo "Installing glab"
    - export GITLAB_TOKEN=$GITLAB_TOKEN_OPENCODE
    - apt-get update --quiet && apt-get install --yes curl wget gpg git && rm --recursive --force /var/lib/apt/lists/*
    - curl --silent --show-error --location "https://raw.githubusercontent.com/upciti/wakemeops/main/assets/install_repository" | bash
    - apt-get install --yes glab jq
    - echo "Configuring glab"
    - git config --global user.email "opencode@gitlab.com"
    - git config --global user.name "Opencode"
    - GITLAB_HOST=https://gitlab.com
    - GITLAB_TOKEN=$CI_JOB_TOKEN
    - echo $GITLAB_HOST

I'll explain how we dynamically configure opencode. As I mentioned earlier, you need to provide the LLM_ENDPOINT and LLM_KEY variables for the pipeline to function properly. This job therefore requires both CI/CD variables to be properly initialized.

The "model" property specifies the default model for opencode. It's composed of the provider name ("back" in this case) and the specific LLM name ("gpt-oss-120b").

You can customize additional parameters such as allow reasoning or use tools. Here is the link to the official opencode config documentation.

    - echo "Creating opencode auth configuration"
    - mkdir --parents ~/.local/share/opencode
    - |
      cat > ~/.local/share/opencode/opencode.json << EOF
      {
        "$schema": "https://opencode.ai/config.json",
        "model": "back/gpt-oss-120b",
        "provider": {
          "back": {
            "npm": "@ai-sdk/openai-compatible",
            "options": {
              "baseURL": "$LLM_ENDPOINT",
              "apiKey": "$LLM_KEY"
            },
            "models": {
              "gpt-oss-120b": {
                "name": "gpt-oss-120b",
                "tool_call": true,
                "reasoning": true,
                "limit": {
                  "context": 128000,
                  "output": 128000
                },
                "options": {
                  "tools": true,
                  "reasoning": true
                }
              }
            }
          }
        }
      }
      EOF

In this step, we execute a prompt from the gitlab-ci.prompt1.md file using opencode. More about the prompt in the following section.

    - echo "Running Opencode"
    - opencode -version
    - PROMPT1=$(cat ./gitlab-ci.prompt1.md)
    - echo -e "\n \n"
    - opencode run "$PROMPT1"

Next, we analyze the ./smell_analysis.json file and determine whether we should proceed or if the 'safety_score' is too low to allow the code to be merged.

    - CURRENT_SAFETY_SCORE=$(cat ./smell_analysis.json | jq .safety_score)
    - echo "Safety score $CURRENT_SAFETY_SCORE. It is supposed to be better than $SAFETY_SCORE to continute."
    - |
      if [ $CURRENT_SAFETY_SCORE -le $SAFETY_SCORE ]; then
         echo -e "The safety score of the changes is lower than our standards allow. This is a blocker. \n \n \033[31mYou shall not pass!!!\033[0m  \n \n"
         exit 1
      fi

The final stage of this pipeline job requires the ./smell_analysis.json file to be present. This file should be generated by opencode, but the question is: how does that happen?

Here comes...

The prompt

The key lies in the prompt. This is what opencode executes to perform code analysis and generate recommendations, including a 'safety_score' that's formatted for easy parsing with jq.

# Code Review Analysis Prompt for ClaudeCode

## Objective
You are an AI assistant tasked with evaluating code changes in a GitLab environment to identify code quality issues and assess their impact on the codebase.

## Primary Tasks

### 1. Code Difference Analysis
Analyze the output of `git diff main` to identify:
- Code quality issues and "code smells"
- Potential problems that changes could introduce
- Risks to existing workflows or data flows
- Complications for future codebase maintenance

### 2. Safety Index Calculation
Compute a **safety index** on a scale of **0 to 10**:
- **10**: Exemplary code with no identifiable issues
- **7-9**: Good code with minor improvements needed
- **4-6**: Acceptable code with moderate concerns
- **1-3**: Poor code with significant issues
- **0**: Critical problems, violations, or data risks present

### 3. Actionable Recommendations
Generate a comprehensive list of specific, actionable suggestions to improve the safety score.

## Output Requirements

### Documentation Quality
- Provide **thoughtful, detailed explanations** for every suggestion
- Each suggestion must include:
  - **At least 3 sentences** of explanation
  - **Specific file references** whenever possible
  - **Line number citations** where applicable
  - Clear reasoning for why the change matters


### Screen Output

Print the analysis results to the standard output using Markdown text formatting. Make the text easy readable in a log file. Add two empty lines before and after the analysis output. 

### File Output
Save the analysis results to a local file named `smell_analysis.json` in the following JSON format:

{
  "safety_score": 5,
  "suggestions": [
    "1: Remove all instances of hardcoded configuration values in src/config.py lines 15-23. These values should be moved to environment variables or a configuration file to improve security and deployment flexibility. Hardcoded values make it difficult to maintain different configurations across environments and pose security risks.",
    "2: Ensure that all new dependencies in requirements.txt are properly versioned and pinned to specific versions. Using unpinned or loosely versioned dependencies can lead to unexpected behavior when packages are updated. This is particularly important for the newly added 'requests' and 'pandas' libraries.",
    "3: Add comprehensive unit tests for all new code in the user_service.py module lines 45-120. The new authentication logic introduces critical security functionality that must be thoroughly tested. Include tests for edge cases, error handling, and security scenarios to prevent vulnerabilities."
  ]
}

## Important Notes
- Focus on substantive issues that affect code quality, security, maintainability, or performance
- Prioritize suggestions by impact (most critical first)
- Be specific and constructive in all feedback
- Reference concrete examples from the diff whenever possible
- Before executing any bash tool command show the command you are going to execute

The output

That is how it looks when the pipeline fails:

Here is a real example of the output when no serious issues were found in the code:


### Safety Index: 6/10

The code changes introduce significant functionality improvements but also present several areas of concern that affect maintainability and potential security.

### Detailed Suggestions

**1: Memory leak risk in conversation history management in app/main.py lines 44-69. The in-memory conversation_history dictionary will grow indefinitely as new session IDs are created, potentially consuming all available memory over time. This should be replaced with a proper database or implement session expiration/cleanup mechanisms to prevent memory exhaustion in production environments.**

**2: Insufficient input validation and sanitization in app/main.py lines 118-119. The HTML tag removal using regex `re.sub(r"<[^>]+>", "", message)` is inadequate for preventing XSS attacks and could miss malicious content. This should be replaced with a proper HTML sanitization library like bleach or html-sanitizer that provides comprehensive XSS protection.**

**3: Hardcoded session management limitations in app/main.py lines 167-170. The history limit of 13 messages is arbitrary and may not suit all use cases or model contexts. This should be configurable through environment variables and include proper validation to ensure the limit doesn't exceed the model's context window capabilities.**

*** skipping for clarity *** 

**8: Missing rate limiting per session in app/main.py. The current rate limiting is only IP-based, which could be bypassed by using different IPs or proxy networks. This should be supplemented with session-based rate limiting to prevent abuse even when IP addresses change.**

The most interesting part is that you can copy-paste this analysis to your current coding agent and improve your posture.

The links

http://chat.roki.cool/
https://opencode.ai/docs/config/
https://learn.microsoft.com/en-us/azure/ai-foundry/foundry-models/concepts/models-from-partners?view=foundry
https://gitlab.com/rokicool/test-opencode-agent

PS

Ideas, suggestions, comments? Don't hesitate!

And by any means this code is not written in stone. Everything might be rewriten, improved or removed.

HCP Terraform to Azure Cloud using OIDC

Roman Kiprin — Fri, 07 Mar 2025 00:30:58 +0000

The usecase

We need our HCP Terraform Workspace to deploy resources to Microsoft Azure without using secrets, tokens, passwords, or anything similar.

Challenging? Not really. We just need to configure OpenID Connect. Continue reading if you need details.

Prerequisites

Obviously, we need to obtain:

the Azure subscription (with the Owner role access),
the HCP Terraform Workspace,
a GitLab (or any other supported by HCP Terraform VCS) project with the Terraform code. (However, the GitLab integration is slightly outside of the scope of this post.)

Let's pretend we have HCP Terraform workspace

It is crucial to know

the name of the organization: rokicool-tf
the project: dev-to
the name of the workspace: azure-automation-account-dev

We will use these identifiers later.

And imagine we have a new shiny Azure subscription:

We need to know the Azure subscription ID and the Tenant ID. If you are not sure if your subscription is located in the root management group or not, just open the Entra ID interface in the Azure Portal. The first thing you'll see will be the Tenant ID.

Subscription ID 971307eb-329d-47a2-b3f2-d424f4da5461
Tenant ID 86abb60f-b63e-475e-85dd-9fa6e1d9f754

Service Principal to represent HCP Terraform Workspace

Our HCP Terraform Workspace should have identity to access the Azure subscription to deploy/destroy resources.

Let's create one.

Azure portal, Entra ID, App Registrations, + New Registration...

Entering it's name... sp-azure-automation-account-deployer-tfc

And here it is:

The only significant part is...

The Client ID 348c0fdc-b20f-4fe7-a79a-872068ff22fd

Give it a role!

The identity cannot do much (access Entra ID with read permissions) by default. You need to assign it a role on the necessary scope.

The details about the possible role and the correct scope are far beyond this post. So, let's say we want to give it Contributor on the scope of subscription.

Federated Credentials for the Service Principal

Everything before this point was a preparation. Now the magic comes!

HashiCorp provides a very comprehensive document Use dynamic credentials with the Azure provider which explains a lot. Especially Configure Microsoft Entra ID Application to Trust a Generic Issuer section.

However, it's outdated a little! We are going to use one flexible federated credential instead of two static ones (as the official document suggests).

First, we need to build a string that is called Subject identifier. The template is

organization:<my-org-name>:project:<my-project-name>:workspace:<my-workspace-name>:run_phase:plan

In our example, the string will look like this:

organization:rokicool-tf:project:dev-to:workspace:azure-automation-account-dev:run_phase:plan

and...

organization:rokicool-tf:project:dev-to:workspace:azure-automation-account-dev:run_phase:apply

... for the second federated identity credentials.

But!

We are going to use Claims matching expression instead of the Explicit subject identifier!

Therefore, our string will look like this:

claims['sub'] matches 'organization:rokicool-tf:project:dev-to:workspace:azure-automation-account-dev:run_phase:*'

Do you see? It is an expression, and the "*" symbol matches both plan and apply phases!

The rest of the fields are described in the mentioned document:

Federated credential scenario: Must be set to Other issuer
Issuer: The address of HCP Terraform (e.g., https://app.terraform.io)
Name: A name for the federated credential, such as `tfc-azure-automation-account-dev'
Audience: api://AzureADTokenExchange by default.

Let's put them in the correct place.

Portal - Entra ID - App registrations - search for you sp - Manage/Certificates & secrets - Federated credentials - +Add credential

Here is what you should see:

Believe me, I am tired too! But bear with me for one more step!

HCP Terraform Workspace Variables

The Azure and Entra ID sides are ready. The next thing is to define several variables for your HCP Terraform workspace to inform Terraform Cloud that you want it using OIDC.

But before doing this, I need to mention another caveat that HashiCorp mentions in their documentation.

Here is the quote:

Make sure that you’re passing values for the subscription_id and tenant_id arguments into the provider configuration block or setting the ARM_SUBSCRIPTION_ID and ARM_TENANT_ID variables in your workspace.

Make sure that you’re not setting values for client_id, use_oidc, or oidc_token in the provider or setting any of ARM_CLIENT_ID, ARM_USE_OIDC, ARM_OIDC_TOKEN.

So, simply speaking, your provider block should look like this:

provider "azurerm" {
features {}

tenant_id = var.tenant_id
subscription_id = var.subscription_id
}

(Unfortunately, dev.to stopped supporting my code block, so I had to use quotes above.)

If it is, we are ready to set up the variables!

Name	Type	Value	Meaning
`TFC_AZURE_PROVIDER_AUTH`	`env`	`true`	Enable OIDC authentication
`TFC_AZURE_RUN_CLIENT_ID`	`env`	`348c0fdc-b20f-4fe7-a79a-872068ff22fd`	The Client ID of the Service Principal you created earlier
`tenant_id`	`terraform`	`86abb60f-b63e-475e-85dd-9fa6e1d9f754`	Entra ID Tenant ID, which you use
`subscription_id`	`terraform`	`971307eb-329d-47a2-b3f2-d424f4da5461`	ID of the Azure subscription you use

Here is how it looks within HCP Terraform Workspace interface:

And... Congrats! You have done it!

Now every push to your GitLab dev-tfc branch will initiate an HCP Terraform Workspace pipeline run, which will definitely deploy your resources.

And an unexpectedly nice thing... you will see an additional stage in your GitLab pipeline that will show the status of the HCP Terraform pipeline run.

What? You did not set up the VCS GitLab integration? Sorry, bro. Next time!

Results

That is how success looks on the HCP Terraform side:

And here is the resource in Azure:

Useful documents

Use dynamic credentials with the Azure provider
Flexible federated identity credentials (preview)

About identities and the services. For those with harmful intentions.

I am absolutely sure that knowledge of the IDs of Tenant, Subscription, and even Service Principal will not help to get access to this infrastructure.

Despite that, I usually delete the identities before publishing my post. So, don't bother.

Wildcards in Federated Credentials Entra ID (OIDC)

Roman Kiprin — Sun, 29 Dec 2024 02:44:07 +0000

That is a gorgeous present for Christmas and New Year from Microsoft!

As of the end of 2024, Microsoft Entra ID started the public preview of the new feature Federated Credentials!

Here is the official Microsoft documentation about that.

What is Federated Credentials and why is it important?

That is a set of properties and technology that allow to define which external security credentials can be trusted.

Simple!

In Entra ID, you can create a Security Principal identity. Then you can assign this identity with rights: Roles or Permissions within both Entra ID and Azure Cloud.

Any outside service that wants to use the identity must provide credentials. Secrets are the easiest way to do it, but they are also the least safe.

Entra ID supports secretless authentication via Federated Credentials.

So, we can create identities and use them without secrets, right?

Precisely! I wrote an article GitLab, Azure, OpenTofu, and NO secrets! about that.

The most important thing is that you can define a subject field with precise reference to external identity. And that will allow your external identity to associate itself with identity in Entra ID.

That subject definition allows a GitLab pipeline from the rokicool/gitlab-azure-oidc-opentofu project that is executed from the main branch to access our Entra ID identity.

Can you see the name of the project and the branch name in the subject:

project_path:rokicool/gitlab-azure-oidc-opentofu:ref_type:branch:ref:main
?

Don't be scared. If you feel overwhelmed, just look over the mentioned article.

OK. That Federated Credentials thing has been here for years. That is the fuss now?

We are close! Bear with me!

The subject of the Federated Credentials requires explicit, exact reference.

That works perfectly with the main branch! Your pipeline from the main branch can authenticate itself easily.

What if you need to authenticate a pipeline from a feature branch?

Here is the use case. Your developer works on a feature AAA and creates a branch 'feat-JIRA-AAA'. How to authenticate a GitLab pipeline in Entra ID using Federated Credentials? And remember that Entra ID supports only 20 federated credentials per identity.

I can hear your deep sights.

Rejoice! Here are wildcards now!

Instead of an explicit subject, you can define a matching expression.

In our example, it will be something like this:

claims['sub'] matches 'project_path:rokicool/gitlab-azure-oidc-opentofu:ref_type:branch:ref:feat-JIRA-*'

Can you see that the name of the branch is dynamic? So every brach in this project whose name starts with feat-JIRA- will be authenticated! Using one record in the Federated Credentials!

Isn't it cool?

Complicaitons

Wildcards might be tricky, and they might provide access when you don't expect it. That's your responsibility now.

The AUD field. GitLab and Microsoft have different vision

audiences field is part of the Federated Credentials and OIDC protocol.

Microsoft claims that

This field is mandatory and should be set to api://AzureADTokenExchange for Microsoft Entra ID

At the same time, GitLab always puts https://gitlab.com to this field.

But. You can write https://gitlab.com there, and your authentication will work:

Using command line instead of the Portal

Just as it was written in the Microsoft documentation, you can use the az rest command to create the Federated Credentials.

Of course, you should be authenticated as owner of the service principal or higher.

Here is the example that worked for me perfectly:

export OBJECT_ID=<OBJECT_ID (not APP_ID!!!) of your applicaiton or Service Principal>

az rest --method post \
    --url https://graph.microsoft.com/beta/applications/$OBJECT_ID/federatedIdentityCredentials \
    --body "{'name': 'FlexFic2', 'issuer': 'https://gitlab.com', 'audiences': ['https://gitlab.com'], 'claimsMatchingExpression': {'value': 'claims[\'sub\'] matches \'project_path:rokicool/gitlab-azure-oidc-opentofu:ref_type:branch:ref:feat-JIRA-*\'', 'languageVersion': 1}}"

Good luck!

Flex Consumption is not cheap (when in private VNET)

Roman Kiprin — Thu, 19 Dec 2024 02:08:11 +0000

I have been working with Flex Consumption plan-based Azure Function Apps for several months and was super enthusiastic about the value.

The Flex Consumption plan produces stable funding for script-defined automation and costs pennies. It allows integration with your private VNET and could be used within a private network environment.

Is it really that good?

Unfortunately, there is no direct answer, and let me explain why.

Azure Function App uses Storage account

Yep. Every Azure Function App utilizes the Azure Storage account to (ha-ha) function. The code of the Function App is located on the Storage account and should be available to the Azure Function App at every moment.

Which is fine. The price of the Storage accounts is reasonable and depends on the amount of data. And that could not be a lot. So the problem is not the Storage account itself.

Private Endpoints are the problem!

Again, when you run your Azure Function App in private, that literally means all the services must run in private and cannot be accessed from the Internet.

As I explained in the previous articles (Azure Function App (Flex Consumption) in private VNET via IaC), you have to build an internal connection between the Azure Function App and the Azure Storage account.

How? You have to setup (at least) two private endpoints for the blob and file services of the Storage account. It is not difficult, but there are some details that must be addressed. That is precisely the point of the mentioned article.

Every private endpoint is billed for time. It costs 1 cent per hour. Which seems to be close to nothing... But...

1 cent per hour sums to about $7.2 per month. And there are two of them, so ~$15 per month.

Here comes Durable Functions stuff

What Durable Functions? Yep. That is another really great technology that deserves much longer article.

Basically, Durable Functions fix the natural limitations of the Azure Functions.

For example, any HTTP-triggered function must return something within 230 seconds. And what if you need more than 240 seconds to gather the results? Or, the grace period of Azure Function is 60 minutes. What if you need more time to execute your automation?

Durable Functions resolve that. They bring the 'context' term into Azure Functions. That gives the possibility of the longer run, control of the run, statuses of the run, and more good things.

But how is that related to this post?

Directly! Durable Functions libraries use the queue and the table services of the Azure Storage account!

From our ("Azure Function in the Private") standpoint, that means we have to create, support, and pay for two more private endpoints for these services!

Final calculation

So, these four private endpoints will cost you ~$7.2 x 4 = ~$30 per month.

Which is still very reasonable, but not cheap.

And don't forget that you probably need to support at least two environments: DEV and PROD. Which makes it $60.

In case you are not afraid

It is still a very robust solution.

And in this 🦊GitLab repo (azure-function-app), I created an end-to-end automated solution that deploys two infrastructures, builds the PowerShell-based Azure Function App, and deploys it to your private VNET.

And yes, the Durable Functions are supported too! Just do not forget to set CI/CD variable AZURE_IS_DURABLE_FUNCTION to 'true'.

Azure Function App (Flex Consumption) PowerShell Modules solution

Roman Kiprin — Sat, 07 Dec 2024 23:49:02 +0000

Prewords

In this article, I explain a technique that allows embedding PowerShell modules in Azure Function based on the Flex Consumption plan.

The fully working example is available in my GitLab project azure-function-app which is devoted to the Flex Consumption plan Azure Functions.

Back to the article

I have to admit that PowerShell is not suitable for high-load applications.

This scripting language is excellent for automating tasks. It offers numerous options for data management, API access, output, logging, error handling, and so much more.

Evidently, the bare language does not support millions of possible operations. You need to use PowerShell modules.

When you organize your PowerShell scripts within Azure Function Apps, things with PowerShell modules become complicated.

Basically, you can use

Install-Module Important-Module
Import-Module Important-Module

and it will work... but. You probably don't want to do it. Every Azure Function execution will trigger that operation. This implies that each execution will involve the download and unpacking of the modules.

PowerShell Azure Function Apps and modules

And that is why the Azure Function PowerShell template has file requirements.psd1 which looks like this:

# This file enables modules to be automatically managed by the Functions service.
# See https://aka.ms/functionsmanageddependency for additional information.
#
@{
    # For latest supported version, go to 'https://www.powershellgallery.com/packages/Az'. 
    # To use the Az module in your function app, please uncomment the line below.
    # 'Az' = '13.*'
}

Which is super useful—you only need to request the modules. The hidden engine will install and cache them.

However, that is not exactly correct when you use the Flex Consumption Plan.

What is with Flex Consumption?

Flex Consumption Plan uses a different approach. Your function does not reserve any computing power; you only pay for executions and resources. This is an excellent feature! You don't pay for reservations.

However, at the same time, your function loses the ability to cache modules.

Should we return to dynamic installation of them? No! Of course not!

And what is the issue with PowerShell modules?

Microsoft suggests that your PowerShell Azure Function should include the necessary modules in the Azure Function distribution package.

That means both your function and the modules will be installed within the same filesystem in the backend Storage account.

It is like'manual caching'. Everything is reachable by the Azure Function App.

There is another problem, though. You have to include the modules in your function repository. And that is a manual process.

Possible solution is...

That is why I wrote all of it.

Why don't we use the pipeline that builds the Azure Function distribution package to automatically include all the necessary PowerShell modules?

Here in my repository: rokicool/azure-function-app@gitlab, you can find an example.

There is a requiredModules.ps1 file that defines the requirements:


# requiredModules.ps1
# List the modules that will be embedded into Azure Function App deployment
$requiredModules = @{
   "Az.Accounts" = "3.0.5"
}

And there is a installModules.ps1 PowerShell script that is expected to be used in the GitLab pipeline:

build:
  stage: build
  image: 
    name: mcr.microsoft.com/azure-powershell:mariner-2
  script:
    - tdnf install zip -y
    - pwsh ./azure-function/Modules/installModules.ps1 ## <-- HERE
    # Build the zip file with the code of the Azure Function
    - mkdir dist
    - cd ./azure-function
    - zip -r ../dist/azure-function.zip ./*
  artifacts:
    paths:
      - dist/azure-function.zip
    name: ${ARM_AZFUNC_NAME}_artifact

Therefore, the distribution package includes all the requested modules. You just need to provide names and the versions.

Let's step back and think!

Instead of requesting and installing the PowerShell modules dynamically, this technique puts the modules in the package alone with your Azure Function scripts!

It is even better from the reliability perspective. Your modules will be with your Azure function as long as your function exists.

Win-Win.

BTW. Since you spent your time on this article, you might be interested in the previous one that explains about Azure Function App (Flex Consumption) in private VNET via IaC

Azure Function App (Flex Consumption) in private VNET via IaC

Roman Kiprin — Sat, 30 Nov 2024 16:53:03 +0000

A lot of technical terms in the name of the article, right? Let's dive into it!

Why Azure Function App?

It is not a serious question! Azure Function App is a fantastic serverless infrastructure that allows you to execute your code within a secure environment.

What if you need to perform a maintenance task by schedule? Or execute a PowerShell script within your Azure subscripton to perform a specific operation?

Azure Function App might perform it for you!

There are challenges, of course. This article explains how to overcome them and have an automated pipeline that creates infrastructure and then builds and deploys Azure Function to the correct place!

Why private VNET?

That is the weirdest part. However, some companies prohibit the use of any Azure service with a publicly accessible interface!

There will be more on that later in this article.

Why Flex Consimption?

Microsoft provides several plans for the Azure Function Apps. They are reasonable.

If you have heavy traffic and a lot of executions, your choice is the Premium Plan: about $200 per month...

What if you need to execute your function only several times per day?

So, with all possible options, we don't have a choice. Only Flex Consumption costs about $3 a month (with less than 1000 executions, remember?) And a Flex Consumption Plan-based App might be integrated into a VNET.

2024.12 UPD: Unfortunately, not $3 but $30 per month. Here is the post about that Flex Consumption is not cheap (when in private VNET)

Some technical internals of Azure Function App

To explain the challenge, I need to surface several technical details. Azure Function App is not exactly a separate service.

The usual Azure Function App has to use other Azure services. Some of them are optional, and some of them are mandatory.

Having an Azure Storage Account is a must. The Azure Function App uses the Storage Account to store the Azure Function Code. However, Azure Storage Account is a publicly available service!

The Function App must be able to access the green circle on the next schema. But that means absolutely everyone (who has the permission, of course) can access it too!

If we need to comply with the company's policy, we must turn off that green public interface of the Storage Account.

But how does the Azure Function App reach the Storage Account for the function code?

We should use a private VNET! That means a lot of things:

we should create Storage Account private endpoints for both Blob and File services;
we should integrate Azure Function App with one of the subnets in private VNET;
we should create DNS zone and DNS names that would allow Azure Function App to find out the private IP addresses of the Storage Account services;
we should provide Azure Function App with the correct DEPLOYMENT_STORAGE_CONNECTION_STRING;
we should allow Azure Function App identity to access the Storage Account.

More details you can find in the official Microsoft document How to use a secured storage account with Azure Functions

GitLab pipeline

A lot of technical things that must be performed for every Azure Function App deployment... So, that must be automated!

Here is my GitLab project that deploys an Azure Function App based on the Consumption Flex plan: azure-function-app

The pipeline first creates infrastructure according to all the steps mentioned above. Then, the pipeline deploys the code of the Azure Function to the infrastructure created on the first step.

The same pipeline supports two environments: DEV and PROD. The plan is to push all changes to the dev or dev_bicep branches to the DEV environment. Any changes made to the main branch will then be sent automatically to both the DEV and PROD environments.

You might find more details in the pipeline definition and the projects README.md file.

BTW, this pipeline does not use secrets. The authentication is based on OIDC (Open ID Connect). I have written an article that provides a detailed explanation of this method: GitLab, Azure, OpenTofu, and NO secrets!.

Why was this article written?

I tried to automate the Azure Function App (Flex Consumption Plan) deployment behind firewalls using Terraform, and I failed.

As of November 2024, Terraform providers don't support subnet integration with the Azure Function App based on the Flex Consumption Plan.

You can find my Terraform-based failing deployment in the dev branch of azure-function-app project.

I really prefer to use Terraform, and as soon as it supports Flex Consumption network integration, I will try to revive this project.

So, Terraform fails. But you can set up that Azure Function App configuration manually via the Portal. This implies that either the ARM Template or Bicep should function properly. I took the Microsoft Official Bicep Template, modified it to support network integration, and here it is, up and running.

As a result, I spent so many hours setting everything up, so I decided to share the findings and working example.

Questions, suggestions...

As you may have noticed, there are numerous areas for improvement. Or I could make a mistake that slipped out of my consciousness.

Please feel free to ask questions or share your suggestions. In fact, I need your feedback to understand where to dig next!

GitLab, Azure, OpenTofu, and NO secrets!

Roman Kiprin — Sat, 28 Sep 2024 21:51:51 +0000

Believe it or not, you can deploy any resource using Terraform from the GitLab pipeline to the Azure cloud without any secrets!

Imagine... No secrets, no maintenance, no KeyVaults, no hassle.

Let me show you how!

The GitLab project

To demonstrate the technique I will use this project gitlab-azure-oidc-opentofu.

What does it do? It creates a Resource Group in one of the Azure Subscriptions. Is it too simple? Yes, it is. However, the main goal is to show how to set up an OpenID Connect (OIDC) authentication.

Everything was set up and running. But as you read this, the Azure subscription has probably been canceled. Just in case somebody manages to merge terraform code that pushes 100 nodes Azure Kubernetes cluster :).

And one more thing to mention.

The OIDC technology works perfectly well with Terraform. In this project, however, I chose to use OpenTofu. It is integrated into the component that is supported by GitLab.

So, the pipeline in this project might be a good example of using the OpenTofu component along with GitLab Terraform state service.

Let's start from the end...

Terraform Code

Here is the full providers.tf file.

Have a look at the terraform code, shall we?

provider "azurerm" {
  features {}

  tenant_id       = var.tenant_id
  subscription_id = var.subscription_id
  client_id       = var.client_id

  use_oidc        = true
  oidc_token      = var.oidc_token
}

All these provider settings are used for authentication. And the two last lines make Terraform (OpenTofu) use OIDC!

Where are these variables set up and what values are used? Great question!

Gitlab pipeline code

The variables are set up within the pipeline code! Here is the link to the pipeline.

There are several details that I would like to highlight.

OIDC token

Yes. I lied in the title. There is a secret used in this technology. However, this secret is orchestrated by technology itself. OpenID Connect provides your code with a temporary OIDC token. This is precisely what is supposed to be put into the oidc_token variable. But how?

Simple!

Every job that requires authentication has these several lines:

...
  id_tokens:
    TF_VAR_oidc_token:
      aud: https://gitlab.com
...

These lines create an environment variable TF_VAR_oidc_token and fill it with the token value.

And that is all you need! From the Terraform code perspective. OK. Almost all you need.

Since the environment variable is set as TF_VAR_<something>, Terraform (OpenTofu) will take its value and set an internal variable with the <something> name. It will be oidc_token in our case.

And this is exactly what our Terraform code expects!

Other Terraform (OpenTofu) variables

Right. It is not enough to set up only a token. The code requires tenant_id, subscription_id, and client_id. Where were these set up?

Simple. These are global variables of the pipeline.

variables:
...
  TF_VAR_client_id: $AZURE_CLIENT_ID
  TF_VAR_tenant_id: $AZURE_TENANT_ID
  TF_VAR_subscription_id: $AZURE_SUBSCRIPTION_ID
...

And here I use the same TF_VAR_<something> notation. So, Terraform (OpenTofu) will take anything that goes after 'TF_VAR_' and create an internal variable with the <something> name.

For example, Terraform (OpenTofu) will take

TF_VAR_client_id: $AZURE_CLIENT_ID

line, create variable client_id and fill it with the value of $AZURE_CLIENT_ID variable.

Great! But, what are $AZURE_CLIENT_ID, $AZURE_TENANT_ID, $AZURE_SUBSCRIPTION_ID?

A very good question. Again! Ten points to Gryffindor! But I am from Slytherin! OK. Minus ten points to Slytherin!

First, let me explain where these variables are set up. And then where their values are taken from.

GitLab CI/CD Variables

These are GitLab CI/CD Variables. To create them, you need to use the Settings / CI/CI / Variables interface of GitLab.

You probably have another couple of questions.

Why do you use CI/CD Variables?

That is not a real question. There is a concept of separation of
data and logic. It's about 75 years old. :)

Yes, it is possible to put these IDs directly into the code. That makes the code unique, and less flexible and limits the usage of the code.

And why don't you create them in TF_VAR_<something> notation?

That is another concept. Never use global variables in a subroutine. :)

It was possible to set up CI/CD Variables with TF_VAR_<something> notation. However, it would make these variables hidden. One should guess the source of data. Now everything is visible and it is much simpler to understand the code.

The Azure or rather Entra ID side

Let us dive into the meaning and source of the $AZURE_CLIENT_ID, $AZURE_TENANT_ID, $AZURE_SUBSCRIPTION_ID variables.

I believe Subscription ID and Tenant ID are self-explanatory, right? Just in case, the Subscription ID is visible almost on every interface of portal.azure.com.

Tenant ID is slightly harder to find out. The quickest way is to search for 'Entra ID' in the portal, open 'Entra ID' and you will see it immediately:

Don't close it yet.

What is the `$AZURE_CLIENT_ID`?

It is an identifier of the Service Principal (or App Registration) you created to authenticate your pipeline.

If you did not, here is how to do it. Open your Entra ID portal, find the App Registrations blade, and press New Registration.

Then provide a meaningful name and press 'Register'.

In my case, the name is sp_azure_subscription_contributor. You can always find your Service Principal in the App Registrations interface of Entra ID.

This is the place where you can find out the Client ID of your Service Principal.

How and where do I provide the Service Principal with access to the Azure subscription?

You created the identity and it must have permission to access your subscription. How to do it? Simple.

Open your subscription in the portal, open the Access control (IAM) blade, and Add role assignment:

Then choose the Contributor Role and, find and choose your newly created Service Principal and assign it.

So, for now, we have everything except the last and most important OIDC ingredient.

The Federated Identity Credentials is Open ID Connect magic

And there is no magic at all. You will need to create the Federated Credentials to allow your pipeline to access your Service Principal credentials without a shared secret.

Open your App Registrations information about your Service Principal. Open the Certificates & Secrets blade. Click on the Federated credentials tab, and press + Add credential

Here is the 'magic sauce':

You can enter whatever you want in the name or description. But it is crucial to provide the correct information in the next fields:

Issuer:

https://gitlab.com

Subject identifier:

project_path:<gitlab_user_name>/<gitlab_project_name>:ref_type:branch:ref:<pipeline_branch_name>

project_path:<gitlab_project_group>/<gitlab_project_name>:ref_type:branch:ref:<pipeline_branch_name>

In my case, it is:

project_path:rokicool/gitlab-azure-oidc-opentofu:ref_type:branch:ref:main

Audience:

https://gitlab.com

And that is all. Here is the Resource Group created by the demo pipeline:

Useful links

GitLab Official Azure AD Federated Identity Credentials Documentation
GitLab OpenTofu Component

UPD 2024.12: Microsoft started supporting wildcards! Here is my post about that: Wildcards in Federated Credentials Entra ID (OIDC)

How do you automate PIM for Groups? (Part 3. Expiration time, Policies, and experiments)

Roman Kiprin — Wed, 24 Apr 2024 19:53:24 +0000

That is the last part of the posts related to 'PIM for Groups' technology.

The links are here:

I am far from proclaiming that these posts cover the entire technology and API. However, my access to the Trial P2 Entra ID license is going to expire, so I need to put the final dot or exclamation mark.

Let us have a look at the expiration

Both 'the PIM eligibility assignment' and 'the activation of the PIM eligibility assignment' have an expiration time.

Let's talk about the 'PIM eligibility assignment expiration.'

How do you get the PIM eligibility expiration time?

Assume that you need to know when the users' PIM eligibility expires.

To access that information, you should make a call to List eligibilitySchedules API using PowerShell function with the ridiculously long name: Get-MgIdentityGovernancePrivilegedAccessGroupEligibilitySchedule

Here is an example:

pwsh> $ea = Get-MgIdentityGovernancePrivilegedAccessGroupEligibilitySchedule -Filter ("groupId eq '{0}' and principalId eq '{1}'" -f $($pg01.Id), $($u01.Id))
pwsh> $ea.ScheduleInfo.Expiration.EndDateTime

Sunday, April 28, 2024 10:38:29 PM

The difference between Portal and PowerShell results is 5 hours. It's probably because PowerShell returns Greenwich time, but Portal shows my local (Central Time).

How do we extend PIM eligibility assignment expiration time?

What if we understand that the expiration time of the PIM eligibility assignment must be postponed?

The answer is... the same Create eligibilityScheduleRequest via PowerShell New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest

pwsh> $params = @{
    accessId = "member"
    principalId = "$($u01.Id)"
    groupId = "$($pg01.Id)"
    action = "adminExtend"
    scheduleInfo = @{
        startDateTime = $(Get-Date)
        expiration = @{
            type = "AfterDateTime"
            endDateTime = $((Get-date).AddDays(14))
        }
    }
    justification = "Expire the PIM eligibility in two weeks."
}

pwsh> New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest -BodyParameter $params

Action      ApprovalId CompletedDateTime     CreatedDateTime       CustomData Id                                   IsValidationOnly Justification                            Status      AccessId GroupId                              Princip
                                                                                                                                                                                                                                       alId
------      ---------- -----------------     ---------------       ---------- --                                   ---------------- -------------                            ------      -------- -------                              -------
adminExtend            4/21/2024 11:11:08 PM 4/21/2024 11:11:07 PM            0d44080f-8c56-41c1-a2ee-730eeff3e397 False            Expire the PIM eligibility in two weeks. Provisioned member   853d7402-51b4-4cd4-9b8d-9f159311859d c88163…

pwsh> 
pwsh> $ea = Get-MgIdentityGovernancePrivilegedAccessGroupEligibilitySchedule -Filter ("groupId eq '{0}' and principalId eq '{1}'" -f $($pg01.Id), $($u01.Id))
pwsh> 
pwsh> $ea.ScheduleInfo.Expiration.EndDateTime

Sunday, May 5, 2024 11:11:06 PM

Success!

And the last thing for today...

How do we assign PIM eligibility permanently?

What if you need to assign PIM eligibility with no expiration? That is tricky.

By default, Entra ID supports a policy that disallows PIM eligibility longer than one year.

What to do? Correct, edit the policy assigned to the PIM group!

To perform that we will require another PowerShell module


pwsh> Install-Module Microsoft.Graph.Identity.SignIns

Untrusted repository
You are installing the modules from an untrusted repository. If you trust this repository, change its InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from 'PSGallery'?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"): y
pwsh> Import-Module Microsoft.Graph.Identity.SignIns

Then, prepare the variables and update the policy based on
Update a rule defined for a policy in PIM for Microsoft Entra roles and expirationPattern resource type

pwsh> $p = Get-MgPolicyRoleManagementPolicyAssignment -Filter $("scopeId eq '{0}' and scopeType eq 'Group' and RoleDefinitionId eq 'member'" -f $pg01.Id)
pwsh> 
pwsh> $unifiedRoleManagementPolicyId = $p.PolicyId
pwsh> $unifiedRoleManagementPolicyRuleId = "Expiration_Admin_Eligibility"

pwsh> $params = @{
    "@odata.type" = "#microsoft.graph.unifiedRoleManagementPolicyExpirationRule"
    id = "Expiration_Admin_Eligibility"
    isExpirationRequired = $false
    target = @{
        "@odata.type" = "microsoft.graph.unifiedRoleManagementPolicyRuleTarget"
        caller = "Admin"
        operations = @(
            "All"
        )
        level = "Eligibility"
        inheritableSettings = @(
        )
        enforcedSettings = @(
        )
    }
}

pwsh> Update-MgPolicyRoleManagementPolicyRule -UnifiedRoleManagementPolicyId $unifiedRoleManagementPolicyId -UnifiedRoleManagementPolicyRuleId $unifiedRoleManagementPolicyRuleId -BodyParameter $params

Id
--
Expiration_Admin_Eligibility

Ta-da!

And now we are allowed to assign PIM eligibility permanently!


pwsh> $params = @{
    accessId = "member"
    principalId = "$($u01.Id)"
    groupId = "$($pg01.Id)"
    action = "AdminAssign"
    scheduleInfo = @{
        startDateTime = $(Get-Date)
        expiration    = @{
            type = "noExpiration"
        }
    }
    justification = "Assign eligible request."
}

pwsh> New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest -BodyParameter $params

Action      ApprovalId CompletedDateTime     CreatedDateTime       CustomData Id                                   IsValidationOnly Justification            Status      AccessId GroupId                              PrincipalId
------      ---------- -----------------     ---------------       ---------- --                                   ---------------- -------------            ------      -------- -------                              -----------            
adminAssign            4/21/2024 11:43:25 PM 4/21/2024 11:43:24 PM            48624c8b-a008-4499-ab60-1922eab76da6 False            Assign eligible request. Provisioned member   853d7402-51b4-4cd4-9b8d-9f159311859d c8816325-d172-44f5-b72…

Let's look at the PIM eligibility assignment via the portal.

Here it is!

Final words

Of course, there are many topics outside of this series, and I never wanted to cover everything. My idea was to cover the 'first steps'—the 'initial direction.'

When I started, I found 0 (zero) explanations, and the documentation was in beta. I spent significant time trying and retrying the API calls to understand how they work.

I recently found a lovely post about PIM for Groups: Automate Assignments with the GraphAPI!. If I had seen it earlier, I would not have written mine. But I believe mine is slightly deeper. :)

Thank you for being with me for that long.

PS. All the tenants, subscriptions, and users from the examples are gone. Please don't bother to search for them. :)

How do you automate PIM for Groups? (Part 2. Playing with PIM for Groups via API)

Roman Kiprin — Sun, 21 Apr 2024 15:16:29 +0000

In my previous text, we sufficiently discussed the PIM for Group's technology. In the first part of this article How do you automate PIM for Groups? (Part 1 - Setup) we prepared our 'infrastructure' and defined our plans.

Let us start with something meaningful! :)

How do we make the user (pim-user-play-01) PIM eligible to activate membership in the PIM Group (PIM-GROUP-PLAY-01)?

You remember that "PIM eligible" means "provided with the ability to activate something via PIM," right?

Here is a .gif video of this action performed 'manually', using Azure Portal:

Now, let's take the same action via Microsoft Graph API.

Here is the link to the API call documentation: Create eligibilityScheduleRequest and the PowerShell module documentation: New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest

pwsh> $u01                                                             

DisplayName      Id                                   Mail UserPrincipalName
-----------      --                                   ---- -----------------
pim-user-play-01 c8816325-d172-44f5-b72d-a1b8de5673c2      pim-user-play-01@Selflearning527.onmicrosoft.com


pwsh> $pg01 

DisplayName       Id                                   MailNickname      Description          GroupTypes
-----------       --                                   ------------      -----------          ----------
PIM-GROUP-PLAY-01 853d7402-51b4-4cd4-9b8d-9f159311859d PIM-GROUP-PLAY-01 PIM for Groups tests {}

pwsh> $params = @{
    accessId = "member"
    principalId = "$($u01.Id)"
    groupId = "$($pg01.Id)"
    action = "AdminAssign"
    scheduleInfo = @{
        startDateTime = $(Get-Date)
        expiration = @{
            type = "AfterDateTime"
            endDateTime = $((Get-date).AddDays(7))
        }
    }
    justification = "$($u01.DisplayName) always deserved to be part of $($pg01.DisplayName)! Stand up, Sir $($u01.DisplayName). You have time until $((Get-date).AddDays(7))!"
}

pwsh> New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest -BodyParameter $params

Action      ApprovalId CompletedDateTime     CreatedDateTime       CustomData Id                                   IsValidationOnly Justification
------      ---------- -----------------     ---------------       ---------- --                                   ---------------- -------------                                                                                             
adminAssign            4/20/2024 11:18:51 PM 4/20/2024 11:18:51 PM            55067776-3b6d-44eb-8337-b0a2ad101bae False            pim-user-play-01 always deserved to be part of PIM-GROUP-PLAY-01! Stand up, Sir pim-user-play-01. You hav…

Let's look at the PIM interface in the Azure Portal:

How do we make ALL security group members (GROUP-PLAY-01) be PIM eligible to activate membership in the PIM Group (PIM-GROUP-PLAY-01)?

That operation is very similar to the previous one. However, instead of assigning PIM eligibility to a User, you can do the same to a Group.

Here is how the 'manual' process looks like:

We will use the same API call.

pwsh> $g01                                                               

DisplayName   Id                                   MailNickname  Description          GroupTypes
-----------   --                                   ------------  -----------          ----------
GROUP-PLAY-01 d8800de8-1e79-4881-8cb3-814c0f6cd935 GROUP-PLAY-01 PIM for Groups tests {}

pwsh> $pg01 

DisplayName       Id                                   MailNickname      Description          GroupTypes
-----------       --                                   ------------      -----------          ----------
PIM-GROUP-PLAY-01 853d7402-51b4-4cd4-9b8d-9f159311859d PIM-GROUP-PLAY-01 PIM for Groups tests {}

pwsh> $params = @{
    accessId = "member"
    principalId = "$($g01.Id)"
    groupId = "$($pg01.Id)"
    action = "AdminAssign"
    scheduleInfo = @{
        startDateTime = $(Get-Date)
        expiration = @{
            type = "AfterDateTime"
            endDateTime = $((Get-date).AddDays(7))
        }
    }
    justification = "Members of $($g01.DisplayName) always deserved to be part of $($pg01.DisplayName)! You have time until $((Get-date).AddDays(7))!"
}

pwsh> New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest -BodyParameter $params

Action      ApprovalId CompletedDateTime     CreatedDateTime       CustomData Id                                   IsValidationOnly Justification
------      ---------- -----------------     ---------------       ---------- --                                   ---------------- -------------                                                                                             
adminAssign            4/20/2024 11:48:15 PM 4/20/2024 11:48:15 PM            ed7561c6-54af-4a71-8d7e-f31cee64fc19 False            Members of GROUP-PLAY-01 always deserved to be part of PIM-GROUP-PLAY-01! You have time until 04/27/2024 …

Let's have a look at the Azure Portal:

Nice! Both the user (pim-user-play-01) and the group (GROUP-PLAY-01) are now PIM eligible to activate membership in PIM group (PIM-GROUP-PLAY-01).

I had to open the Azure Portal and take screenshots to prove this. But is it not possible to perform that operation via Microsoft Graph API? The question urges us to the next topic!

How do we check whether the specific user or group is PIM eligible?

To perform that, we will call to List eligibilitySchedules using PowerShell function Get-MgIdentityGovernancePrivilegedAccessGroupEligibilitySchedule.

pwsh> Get-MgIdentityGovernancePrivilegedAccessGroupEligibilitySchedule -Filter ("groupId eq '{0}' and principalId eq '{1}'" -f $($pg01.Id), $($u01.Id))

CreatedDateTime       CreatedUsing                         Id                                                                               ModifiedDateTime    Status      AccessId GroupId                              MemberType Principal
                                                                                                                                                                                                                                     Id
---------------       ------------                         --                                                                               ----------------    ------      -------- -------                              ---------- ---------
4/20/2024 11:18:51 PM 55067776-3b6d-44eb-8337-b0a2ad101bae 853d7402-51b4-4cd4-9b8d-9f159311859d_member_55067776-3b6d-44eb-8337-b0a2ad101bae 1/1/0001 8:00:00 AM Provisioned member   853d7402-51b4-4cd4-9b8d-9f159311859d direct     c8816325…

pwsh> Get-MgIdentityGovernancePrivilegedAccessGroupEligibilitySchedule -Filter ("groupId eq '{0}' and principalId eq '{1}'" -f $($pg01.Id), $($g01.Id))

CreatedDateTime       CreatedUsing                         Id                                                                               ModifiedDateTime    Status      AccessId GroupId                              MemberType Principal
                                                                                                                                                                                                                                     Id
---------------       ------------                         --                                                                               ----------------    ------      -------- -------                              ---------- ---------
4/20/2024 11:48:15 PM ed7561c6-54af-4a71-8d7e-f31cee64fc19 853d7402-51b4-4cd4-9b8d-9f159311859d_member_ed7561c6-54af-4a71-8d7e-f31cee64fc19 1/1/0001 8:00:00 AM Provisioned member   853d7402-51b4-4cd4-9b8d-9f159311859d direct     d8800de8…

Yes! We have the same results as the 'manual' path already shown.

How do we activate PIM eligibility?

This is precisely why all the technology was created: temporarily activating a role or group membership.

Here is the .gif video of how a user can activate his/her PIM eligibility:

This is how activation is performed via Microsoft Graph API. Here is a link to Graph API Documentation: Create assignmentScheduleRequest and PowerShell Documentation New-MgIdentityGovernancePrivilegedAccessGroupAssignmentScheduleRequest

pwsh> $params = @{
    accessId = "member"
    principalId = "$($u01.Id)"
    groupId = "$($pg01.Id)"
    action = "adminAssign"
    scheduleInfo = @{
        startDateTime = $(Get-Date)
        expiration = @{
            type = "afterDuration"
            duration = "PT2H"
        }
    }
    justification = "Always wanted to try this group!"
}

pwsh> New-MgIdentityGovernancePrivilegedAccessGroupAssignmentScheduleRequest -BodyParameter $params

Action      ApprovalId CompletedDateTime    CreatedDateTime      CustomData Id                                   IsValidationOnly Justification                    Status      AccessId GroupId                              PrincipalId
------      ---------- -----------------    ---------------      ---------- --                                   ---------------- -------------                    ------      -------- -------                              -----------      
adminAssign            4/21/2024 2:25:19 AM 4/21/2024 2:25:18 AM            a24ebfc9-45ac-49bc-ad81-d0d7d3eb6d51 False            Always wanted to try this group! Provisioned member   853d7402-51b4-4cd4-9b8d-9f159311859d c8816325-d172-44…

Here it is! The membership in PIM-GROUP-PLAY-01 is activated!

Perfect! The next question is...

How do we remove PIM eligibility?

What if we need to revoke the ability to activate membership? Is it possible?

Of course! Here is how one could do it 'manually':

In automation, Microsoft Graph API call Create eligibilityScheduleRequest or PowerShell function New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest will help you.

And yes, I have not made a mistake. The same call and PowerShell function created the PIM eligibility! The difference in the parameters of the call.

pwsh>  $params = @{
    accessId = "member"
    principalId = "$($u01.Id)"
    groupId = "$($pg01.Id)"
    action = "adminRemove"
    justification = "It is time to go."
}

pwsh> New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest -BodyParameter $params

Action      ApprovalId CompletedDateTime CreatedDateTime      CustomData Id                                   IsValidationOnly Justification     Status  AccessId GroupId                              PrincipalId                          Target ScheduleId
------      ---------- ----------------- ---------------      ---------- --                                   ---------------- -------------     ------  -------- -------                              -----------                          --
adminRemove                              4/21/2024 2:41:21 AM            9f1bd851-83a9-4a29-b1f7-ff4e8e362b14 False            It is time to go. Revoked member   853d7402-51b4-4cd4-9b8d-9f159311859d c8816325-d172-44f5-b72d-a1b8de5673c2

The exciting bonus stuff!

About that... You know the post is already embarrassingly long.

Let's meet again in 'Part 3 - The Bonus stuff' post!

Meanwhile, I don't pretend to cover everything; I am sure there might be mistakes or typos. Please don't hesitate to comment!

All the '.gif videos' are made with LICEcap

How do you automate PIM for Groups? (Part 1 - Setup)

Roman Kiprin — Sun, 21 Apr 2024 15:13:14 +0000

Recently, I wrote a boring text explaining the advantages of PIM for Groups. Today, I want to step further and show how to automate it.

What? Automate PIM for Groups? Why?

Yep. You can have a list of security group members from your PowerShell script, can you? You can administer a security group membership, right? But can you assign PIM eligibility for a user without expiration from a PowerShell script? I doubt that. However, that is a very similar operation and should be performed easily.

What permissions do we need to begin?

Let us assume that we have an EntraID tenant in which you can have one of two roles: Global Administrator or Privileged Role Administrator.

To read PIM-related data from Entra ID, you might get out with Global Reader, but making any change is only allowed for the two mentioned above.

PowerShell and modules?

The entire post is about using PowerShell to automate PIM for Groups. Technically, you can use any supported language or none since everything is available via Microsoft Graph API. However, the examples here are written in PowerShell.

Today, the latest version is 7.4.

To play with the examples, you will need to install several PowerShell modules:

# Install the required modules
install-module Microsoft.Graph.Groups
install-module Microsoft.Graph.Users
install-module Microsoft.Graph.Identity.Governance
install-module Microsoft.Graph.Identity.DirectoryManagement


# Import them
import-module Microsoft.Graph.Groups
import-module Microsoft.Graph.Users
import-module Microsoft.Graph.Identity.Governance
import-module Microsoft.Graph.Identity.DirectoryManagement

Are we ready? Can we start?

Yes. Almost.

We need to authenticate the PowerShell session against Microsoft Graph and request permissions.

pwsh> Connect-MgGraph -Scopes "Group.ReadWrite.All", "User.ReadWrite.All", "PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup", "Domain.Read.All", "RoleManagementPolicy.ReadWrite.AzureADGroup"

Welcome to Microsoft Graph!

Connected via delegated access using 14d82eec-204b-4c2f-b7e8-296a70dab67e
Readme: https://aka.ms/graph/sdk/powershell
SDK Docs: https://aka.ms/graph/sdk/powershell/docs
API Docs: https://aka.ms/graph/docs

NOTE: You can use the -NoWelcome parameter to suppress this message.

pwsh> get-mgContext

ClientId               : 14d82eec-204b-4c2f-b7e8-296a70dab67e
TenantId               : c23a6ba9-4536-4e44-a7b8-9c643e365d2f
Scopes                 : {Group.ReadWrite.All, openid, PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup, profile…}
AuthType               : Delegated
TokenCredentialType    : InteractiveBrowser
CertificateThumbprint  : 
CertificateSubjectName : 
Account                : RomanKiprin@Selflearning527.onmicrosoft.com
AppName                : Microsoft Graph Command Line Tools
ContextScope           : CurrentUser
Certificate            : 
PSHostVersion          : 7.4.2
ManagedIdentityId      : 
ClientSecret           : 
Environment            : Global

Why do we need these particular permissions?

The short answer - trust me!

If, for some reason, you don't, here is a screenshot of one of the Microsoft Graph API calls List assignmentScheduleRequests:

Every Microsoft Graph API call has a "Permissions" paragraph, and you can perform your research.

You can also look at Microsoft Graph permissions reference. But in this post, I will stop with permissions.

Can we start playing with PIM already?

I know, I know. Let's set up global variables and create/check our Entra ID object!

pwsh> $groupName01    = "GROUP-PLAY-01"
pwsh> $pimGroupName01 = "PIM-GROUP-PLAY-01"
pwsh> $userName01     = "pim-user-play-01"

And then, let's create a couple of groups and ...

pwsh> $g01 = Get-MgGroup -Filter ("DisplayName eq '{0}'" -f $groupName01)
pwsh> 
pwsh> if ($null -eq $g01) {
     $params = @{
         DisplayName = $($groupName01)
         MailEnabled = $False
         MailNickName = $($groupName01)
         SecurityEnabled = $True
         Description = "PIM for Groups tests"
     }
     $g01 = New-MgGroup @params
}

pwsh> $pg01 = Get-MgGroup -Filter ("DisplayName eq '{0}'" -f $pimGroupName01)
pwsh>        
pwsh> if ($null -eq $pg01) {
     $params = @{
         DisplayName = $($pimGroupName01)
         MailEnabled = $False
         MailNickName = $($pimGroupName01)
         SecurityEnabled = $True
         Description = "PIM for Groups tests"
     }
     $pg01 = New-MgGroup @params
 }

pwsh> $g01

DisplayName   Id                                   MailNickname  Description          GroupTypes
-----------   --                                   ------------  -----------          ----------
GROUP-PLAY-01 d8800de8-1e79-4881-8cb3-814c0f6cd935 GROUP-PLAY-01 PIM for Groups tests {}
pwsh>
pwsh> $pg01

DisplayName       Id                                   MailNickname      Description          GroupTypes
-----------       --                                   ------------      -----------          ----------
PIM-GROUP-PLAY-01 853d7402-51b4-4cd4-9b8d-9f159311859d PIM-GROUP-PLAY-01 PIM for Groups tests {}

... a user:

pwsh> $domain = Get-MgDomain
pwsh> 
pwsh> $u01 = Get-MgUser -Filter ("DisplayName eq '{0}'" -f $userName01)
pwsh> 
pwsh> if ($null -eq $u01) {
     $PasswordProfile = @{Password = '<here-should-be-password>'}
     $params=@{
         DisplayName = $userName01
         AccountEnabled = $true
         MailNickName = $userName01
         PasswordProfile = $PasswordProfile
         UserPrincipalName = "$($userName01)@$($domain.Id)"
     }
     $u01 = New-MgUser @params
 }
pwsh> $u01

DisplayName      Id                                   Mail UserPrincipalName
-----------      --                                   ---- -----------------
pim-user-play-01 c8816325-d172-44f5-b72d-a1b8de5673c2      pim-user-play-01@Selflearning527.onmicrosoft.com

So we can confirm the groups...

... and the user are visible via the Portal

What will we do?

I spent quite some time preparing the stage for the demonstration, and the goal of this text might have slipped out a little.

My previous text provides a profound explanation of the PIM for Group technology. Based on its terms, let's say what we will do.

We will make a user (pim-user-play-01) PIM eligible to activate the membership of the PIM Group (PIM-GROUP-PLAY-01).
We will make ALL members of the security group (GROUP-PLAY-01) PIM eligible to activate the membership of the PIM Group (PIM-GROUP-PLAY-01).
We will check if the specific user or group is PIM-eligible.
We will activate PIM eligibility.
We will remove PIM eligibility.
And perform some additional bonus stuff, too.

Stay tuned for the "Part 2. Playing with PIM for Groups via API"!

Let's talk about PIM

Roman Kiprin — Sun, 31 Mar 2024 17:46:05 +0000

Yes, Privileged Identity Management. PIM.

This is a technology that Microsoft provides in Entra ID (former Azure AD). I believe this will be an industry standard, just like they did with Active Directory.

Everyone who works with authentication and system integration should know about it!

Let me explain why you might need it!

Imagine that you work with some system. You need to perform administrative tasks with a higher level of access from time to time. However, it is unsafe always to access the system with such permissions: you can devastate it with one wrong command or misclick of a mouse. Or a virus can access the system using your permissions, causing many problems.

Working with Windows Domains, it was a good practice to have two different accounts: one for ordinary stuff and the other for Administrative purposes only.

It was not super convenient, but it helped a lot with segregating the routines and permissions. So, I had a 'user' role most of the time and an 'administrator' when required.

Microsoft has developed that Role assignment significantly since these days in Entra ID (former Azure AD) and Azure Cloud.

So, Entra ID (former Azure AD). Here is the thing.

Any user is allowed to be assigned any Role in Entra ID. There are about 60 buil-in Roles in it. A role is just a set of permissions to perform operations (or REST API calls if you go more profound).

To avoid providing permissions permanently, Microsoft invented PIM. PIM creates a simple but effective concept.

Instead of a permanent Role, the user is provided with PIM eligibility to activate the Role when necessary.

You can use the PIM interface to activate your Global Administrator Entra ID Role when performing a high-level administration task. I'll skip some details... The user's account will receive the requested permissions in a few minutes.

And then, for example, 4 hours later, the Role permissions disappear. Of course, all activations are logged in to your favorite SEIM.

Cool?

OK. Let's assume there is only one nerd here—myself. But I think it is incredibly cool.

You might think that is all. Nope. It is only the beginning!

What if you need to elevate a user's permissions not in Entra ID but in some other system that uses Entra ID for authentication?

Here is the honey!

Microsoft developed PIM and another technology called PIM for Groups. These are similar but different technologies.

Instead of providing users with Roles in Entra ID - this technology provides users with temporary membership in Entra ID security groups!

PIM for Groups example

Imagine you have two user groups: "Operators" and "Administrators." Membership in "Operators" gives access to The Best AI-Based Infosystem (TBAIBI). Membership in "Administrators" provides both operator and management-level access to the same TBAIBI.

You can make most of the users members of the "Operators" group and some members of the "Administrators" group...

However, you don't want the administrators always to have their permissions active.

What to do?

You make all the users members of "Operators," and some users, via the same PIM interface of Entra ID, are provided with PIM eligibility to temporarily activate membership of the "Administrators" group.

So, when a user needs to perform administrative operations, he/she goes to the Entra ID Privileged Identity Interface (PIM) and activates membership in a higher permissions group! Entra ID starts considering a user an "Administrator" group member in a few minutes. Since then, the external system (TBAIBI) believes the user is an administrator.

Everything is logged, limited by time, managed by policies, filled with settings, and provided with notifications. And everything works without ANY additional functionality in your precious TBAIBI!

Isn't it cool?

I refuse to believe somebody could read the text until this line and think it was not!

There are several not-so-bright things to mention, though.

The shortfalls of PIM for Groups

Nothing comes free and free from issues, so...

This functionality is only available when you buy an Entra ID P2 (or similar) license, which are sold for 9$ per user per month.
It is tough to predict when the elevated permissions will take effect. All process layers are cached, and the caches' expiration is a mystery. (You might want to open a new Incognito window to start a new session and get access to elevated permissions without waiting.)
This new technology went public several months ago, and automation is not widely available.

Something about automation

Our infrastructure uses Terraform to deploy to Azure Cloud and perform operations with Entra ID security groups and users.

Unfortunately, Terraform (provider for AzureAD) does not support PIM for Groups.

Why bother? Let's use PowerShell to fill the gaps, right?

You could start giggling and smiling at this question only a couple of months ago. By today, Microsoft has released the necessary PowerShell modules to the public, and they have documentation.

Microsoft migrated Entra ID management under the umbrella of Microsoft Graph API. If you managed to ignore it until today, you might want to start paying attention.

There is only one thing that I would like to mention. Microsoft stays fair to itself. :)

Let's assume you must perform an automated call to make a user eligible to activate a privileged security group membership. What name would you give such a call?

I am sure you guessed wrong!

It is called New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest

You can think about what name you would give a reverse operation API. You'll never guess!

But I will write about it in the following article.

Some missed details

I intentionally missed some details to avoid going into the weeds.

Both the PIM eligibility and the activation of the PIM eligibility might have an expiration
Microsoft did not invent Roles. I remember srvctl / as sysdba on the tips of my thingers. Hello to you, Tom Kyte's readers!

And much more that I might miss unintentionally. Please fill in the gaps in the comments!

UPD. If you are ready to try some PowerShell here is the link to the continuation: How do you automate PIM for Groups? (Part 1 - Setup).

DEV Community: Roman Kiprin

Code review with private LLM? In pipeline? Simple!

GitLab for code, Azure for LLM, opencode for managing code review

Project to gather all together. It is an LLM chat app, of course.

The schema

The gpt-oss-120b large language model

Microsoft Foundry

The LLM endpoint and secret

The GitLab pipeline

The prompt

The output

The links

PS

HCP Terraform to Azure Cloud using OIDC

The usecase

Prerequisites

Service Principal to represent HCP Terraform Workspace

Give it a role!

Federated Credentials for the Service Principal

HCP Terraform Workspace Variables

Results

Useful documents

About identities and the services. For those with harmful intentions.

Wildcards in Federated Credentials Entra ID (OIDC)

What is Federated Credentials and why is it important?

So, we can create identities and use them without secrets, right?

OK. That Federated Credentials thing has been here for years. That is the fuss now?

Rejoice! Here are wildcards now!

Complicaitons

The AUD field. GitLab and Microsoft have different vision

Using command line instead of the Portal

Flex Consumption is not cheap (when in private VNET)

Azure Function App uses Storage account

Private Endpoints are the problem!

Here comes Durable Functions stuff

But how is that related to this post?

Final calculation

In case you are not afraid

Azure Function App (Flex Consumption) PowerShell Modules solution

Prewords

Back to the article

PowerShell Azure Function Apps and modules

What is with Flex Consumption?

And what is the issue with PowerShell modules?

Possible solution is...

Azure Function App (Flex Consumption) in private VNET via IaC

Why Azure Function App?

Why private VNET?

Why Flex Consimption?

Some technical internals of Azure Function App

GitLab pipeline

Why was this article written?

Questions, suggestions...

GitLab, Azure, OpenTofu, and NO secrets!

The GitLab project

Terraform Code

Gitlab pipeline code

OIDC token

Other Terraform (OpenTofu) variables

GitLab CI/CD Variables

The Azure or rather Entra ID side

What is the $AZURE_CLIENT_ID?

How and where do I provide the Service Principal with access to the Azure subscription?

The Federated Identity Credentials is Open ID Connect magic

Useful links

How do you automate PIM for Groups? (Part 3. Expiration time, Policies, and experiments)

Let us have a look at the expiration

How do you get the PIM eligibility expiration time?

How do we extend PIM eligibility assignment expiration time?

How do we assign PIM eligibility permanently?

Final words

How do you automate PIM for Groups? (Part 2. Playing with PIM for Groups via API)

How do we make the user (pim-user-play-01) PIM eligible to activate membership in the PIM Group (PIM-GROUP-PLAY-01)?

How do we make ALL security group members (GROUP-PLAY-01) be PIM eligible to activate membership in the PIM Group (PIM-GROUP-PLAY-01)?

How do we check whether the specific user or group is PIM eligible?

How do we activate PIM eligibility?

How do we remove PIM eligibility?

The exciting bonus stuff!

How do you automate PIM for Groups? (Part 1 - Setup)

What? Automate PIM for Groups? Why?

What is the `$AZURE_CLIENT_ID`?