ラベル Azure の投稿を表示しています。 すべての投稿を表示
ラベル Azure の投稿を表示しています。 すべての投稿を表示

2024年3月13日水曜日

Azure Devops の pipeline 機能を自動で実行する方法

Azure Devops の pipeline 機能を自動で実行する方法

概要

前回 手動でパイプラインを実行する方法を紹介しました
今回は自動でパイプラインを実行する方法を紹介します

環境

  • Azure Devops (2024/03/07 時点)
  • macOS 11.7.10

azure-pipelines.yml

答え: trigger で batch: true にし自動実行するブランチを指定すれば OK です

サンプル

trigger:
  batch: true
  branches:
    include:
    - master

pool:
  vmImage: "ubuntu-latest"

jobs:
- job: TestJob
  steps:
  - script: |
      echo "Hello, Azure Pipelines!"
      cat /etc/issue
      uname -a
    displayName: 'Run My Command'

最後に

trigger にブランチ名だけ指定した場合は自動では実行されず手動になるので注意しましょう

CI/CD したい場合は batch を使います

参考サイト

2024年3月12日火曜日

Azure Devops で REST API をコールする方法

Azure Devops で REST API をコールする方法

概要

Azure Devops の REST API をコールしてみました
今回はプロジェクトの一覧を取得しています
公式のリファレンスはこちらです

環境

curl

user には Azure Devops で使用しているユーザ名を pta には個人用アクセストークンを入力しましょう
また organization_name の部分も組織名を適宜入力してください

  • curl -u "user:pta" "https://dev.azure.com/organization_name/_apis/projects?api-version=2.0"

レスポンスのサンプルは以下のとおりです

{
  "count": 1,
  "value": [
    {
      "id": "1dd3f062-ec15-4065-9401-bf2266c1fc97",
      "name": "test",
      "url": "https://dev.azure.com/organization_name/_apis/projects/9e67f2f0-9f0b-4be9-8084-42426920a786",
      "state": "wellFormed",
      "revision": 11,
      "visibility": "private",
      "lastUpdateTime": "2024-02-20T02:38:46.713Z"
    }
  ]
}

python

  • pipenv install azure-devops
from azure.devops.connection import Connection
from msrest.authentication import BasicAuthentication

# トークンとAzure DevopsのURLを設定
personal_access_token = "pta"
organization_url = "https://dev.azure.com/xxx"

# コネクションの作成
credentials = BasicAuthentication("", personal_access_token)
connection = Connection(base_url=organization_url, creds=credentials)

# クライアントの作成
core_client = connection.clients.get_core_client()

# プロジェクトの一覧の取得
projects = core_client.get_projects()
for project in projects:
    print(project.name)

ページネイト用の continuation_token というのがあるらしいが取得方法がわからなかったです

最後に

Azure Devops の API を使ってみました
Extension など作る場合や自動化するようなときに使う感じになるかなと思います

参考サイト

2024年3月11日月曜日

Azure Devops で Microsoft Security DevOps を有効にしてセキュリティチェックをしてみる

Azure Devops で Microsoft Security DevOps を有効にしてセキュリティチェックをしてみる

概要

Azure Devsop で Devops sec をするには公式が提供する拡張を使います
Microsoft Security Devops をインストールする方法から今回は trivy を使った静的コードスキャンを使ってみます

環境

Microsoft Security Devops をインストールする

右上のマーケットプレイスボタンから「Browse marketplace」をクリックします

マーケットプレイスの一覧になったら検索バーに「Microsoft Security Devops」を入力します

拡張をインストールする組織を聞かれるのでプルダウンから選択してインストールしましょう

インストールが完了すると拡張の一覧に表示されます

azure-pipelines.yml の編集

Microsoft Security Devops を使って trivy でスキャンするジョブを追加します

  • vim azure-pipelines.yml
trigger:
  batch: true
  branches:
    include:
    - master

pool: test_pool

jobs:
- job: TestJob
  steps:
  - script: |
      echo "Hello, Azure Pipelines!"
      cat /etc/issue
      uname -a
    displayName: "Run My Command"
  - task: MicrosoftSecurityDevOps@1
    displayName: "Microsoft Security DevOps"
    inputs:    
      command: "run"
      policy: "azuredevops"
      languages: "python"
      tools: "trivy"

inputs に複数のオプションを指定できます
とりあえずプロジェクトは python でできているので launguages は python を指定しましょう
また今回は trivy を実行しますが他にも 'bandit', 'binskim', 'eslint', 'templateanalyzer', 'terrascan', 'trivy'. が指定可能です

動作確認

パイプラインを見ると追加した MicrosoftSecurityDevOps@1 タスクが実行されているのが確認できます
自動で trivy をダウンロードして . に対して実行していることが確認できます

最後に

Azure Devops でセキュリティチェックをしてみました
最近ではこんな感じで CI/CD の中にセキュリティチェックを入れる Devops Sec 的なことが主流のようです

今回は MicrosoftSecurityDevOps を使いました
これを使った場合 trivy 以外のセキュリティチェックもできます
もし trivy だけ使いたいのであれば trivy 専用の拡張もあるのでそれを使っても OK です

参考サイト

2024年3月10日日曜日

Azure Devops で独自のエージェントを docker で動かす方法

Azure Devops で独自のエージェントを docker で動かす方法

概要

Microsoft が公式で提供している docker イメージがあるのですがこれはもうすでにメンテナンスされていません
非公式ではありますがメンテナンスされているイメージがあるので今回はそれを使ってみました

環境

最初に

公式の見解としては自分でビルドしてくださいというのが方針のようです
https://learn.microsoft.com/ja-jp/azure/devops/pipelines/agents/docker?view=azure-devops

なので今回紹介するイメージがメンテナンスされなくなった場合などは公式の手順を参考に自分でイメージをビルドして使いましょう

docker 上でエージェントの起動

コマンドは以下のとおりです
エージェントの状態を保持するために /var/azdo/_work をホスト側のディレクトリでマウントしておきます

  • mkdir work
docker run \
  -e AZDO_URL=https://dev.azure.com/xxx \
  -e AZDO_TOKEN=xxx\
  -e AZDO_AGENT=docker \
  -e AZDO_POOL=test_pool \
  -v $(pwd)/work:/azdo/agent/_work \
  -it czon/azdo-agent:ubuntu-20.04-3.234.0

-e AZDO_WORK=/var/azdo/$AZDO_AGENT というオプションで任意のワークディレクリを指定できるのですがなぜかこれを指定すると mkdir: cannot create directory '': No such file or directory になるので指定を外しました

起動ログ

起動が完了した際のログは以下のとおりです

Configure Agent ...

  ___                      ______ _            _ _
 / _ \                     | ___ (_)          | (_)
/ /_\ \_____   _ _ __ ___  | |_/ /_ _ __   ___| |_ _ __   ___  ___
|  _  |_  / | | | '__/ _ \ |  __/| | '_ \ / _ \ | | '_ \ / _ \/ __|
| | | |/ /| |_| | | |  __/ | |   | | |_) |  __/ | | | | |  __/\__ \
\_| |_/___|\__,_|_|  \___| \_|   |_| .__/ \___|_|_|_| |_|\___||___/
                                   | |
        agent v3.234.0             |_|          (commit 21ca259)


>> End User License Agreements:

Building sources from a TFVC repository requires accepting the Team Explorer Everywhere End User License Agreement. This step is not required for building sources from Git repositories.

A copy of the Team Explorer Everywhere license agreement can be found at:
  /azdo/agent/license.html


>> Connect:

Connecting to server ...

コンパネでエージェントの確認

Azure Devops のコンパネでもエージェントが動作しているのが確認できます

少し説明

  • AZDO_URL・・・組織名付きで Azure Devops の URL を指定します、エージェントからは指定のエンドポイントにアクセスできる必要があります
  • AZDO_TOKEN・・・Azure Devops で作成した PAT (個人アクセストークン) を指定します
  • AZDO_AGENT・・・エージェント名を入力します
  • AZDO_POOL・・・エージェントを登録するプール名を指定します、デフォルトでは default プールに作成されます

PAT の取得

こちらを参考に取得しておきましょう

使用できるタグ

現状だと Ubuntu20 が最新のようです
詳しくは dockerhub のタグ情報を確認してください
https://hub.docker.com/r/czon/azdo-agent/tags

最後に

Azure Devops のパイプラインエージェントを docker で起動してみました
非公式のイメージですが自分でビルドするのが面倒な場合には便利です

基本はバイナリですが docker イメージにしておけば k8s 上でも動作可能なので便利です

参考サイト

2024年3月9日土曜日

Azure Devops の pipeline で独自の Pool (Agent) を構築し pipeline を実行する方法

Azure Devops の pipeline で独自の Pool (Agent) を構築し pipeline を実行する方法

概要

前回 パイプライン機能の実行方法を紹介しました
デフォルトでは Microsoft が提供する pool にあるエージェントを使って実行しました
その場合は共有のリソースになるので順番待ちになったりします
今回は独自で Pool (Agent) を構築しパイプラインを実行する方法を紹介します

環境

pool の追加

Project Settings -> Agent pools -> Add pool を選択します

Pool type は「Self-hosted」を選択します
Name には好きな名前の pool 名を指定します (あとで azure-pipelines.yml から指定するのに使います
今回は権限はすべてパイプラインが扱えるようにします

Pool が作成されると一覧に表示されます

エージェントの追加

作成した Pool に Agent を追加します
実際パイプラインが実行されるのは Agent で Pool はエージェントを管理するグループになります

作成した test_pool を選択し右上の「New agent」を選択します

するとエージェントをインストールし構築する手順が表示されるので指示通りにインストールしましょう (手順が古い場合があるので注意、後述に詳細あり

エージェントの構築

azure-pipelines-agent をインストールします

docker でも動作しますが今回は初回なので指示通りバイナリインストールで構築します
ただコンパネで表示されるコマンドのエージェントのバージョンはかなり古いのでリポジトリにある安定の最新版をインストールするようにしましょう
Agent は今回 Ubuntu 上に構築します

  • mkdir azure_devops_agent && cd azure_devops_agent
  • wget https://vstsagentpackage.azureedge.net/agent/3.234.0/vsts-agent-linux-x64-3.234.0.tar.gz
  • tar zxvf vsts-agent-linux-x64-3.234.0.tar.gz
  • ./config.sh
  ___                      ______ _            _ _
 / _ \                     | ___ (_)          | (_)
/ /_\ \_____   _ _ __ ___  | |_/ /_ _ __   ___| |_ _ __   ___  ___
|  _  |_  / | | | '__/ _ \ |  __/| | '_ \ / _ \ | | '_ \ / _ \/ __|
| | | |/ /| |_| | | |  __/ | |   | | |_) |  __/ | | | | |  __/\__ \
\_| |_/___|\__,_|_|  \___| \_|   |_| .__/ \___|_|_|_| |_|\___||___/
                                   | |
        agent v3.234.0             |_|          (commit 21ca259)


>> End User License Agreements:

Building sources from a TFVC repository requires accepting the Team Explorer Everywhere End User License Agreement. This step is not required for building sources from Git repositories.

A copy of the Team Explorer Everywhere license agreement can be found at:
  /home/devops/work/azure_devops_agent/license.html

Enter (Y/N) Accept the Team Explorer Everywhere license agreement now? (press enter for N) > Y

>> Connect:

Enter server URL > https://dev.azure.com/xxx/
Enter authentication type (press enter for PAT) >
Enter personal access token > ****************************************************
Connecting to server ...

>> Register Agent:

Enter agent pool (press enter for default) > test_pool
Enter agent name (press enter for agent01) >
Scanning for tool capabilities.
Connecting to the server.
Successfully added the agent
Testing agent connection.
Enter work folder (press enter for _work) >
2024-03-07 04:56:11Z: Settings Saved.

Server URL は自身の Azure Devops の URL を組織名付きで入力しましょう
プールの選択部分だけ test_pool にします
default でも特に問題ないですが azure-pipelines.yml で指定する pool 名も default にしましょう
他は基本はすべてデフォルトの設定で進めて OK です
設定できたら起動しましょう

  • ./run.sh
Scanning for tool capabilities.
Connecting to the server.
2024-03-07 04:59:08Z: Listening for Jobs

上記のようになれば起動完了です

liblttng-ust0 がない

もし必要なパッケージがまだインストールされていない場合は以下で自動でインストールできます

  • sudo ./bin/installdependencies.sh

詳しいインストール方法はこちらが参考になります

E: Unable to locate package liblttng-ust0 というエラーになる場合は bin/installdependencies.sh を編集して liblttng-ust0 -> liblttng-ust1 に変更して再度実行しましょう

また上記のエラーは azure-pipeline-agent のバージョンが古い場合にも起こるので解決策として最新の azure-pipeline-agent をインストールすると良いでしょう

個人アクセストークン (PAT) の取得

こちらを参考に取得しておきましょう

Azure Devops への疎通

azure-pipeline-agent から Azure Devops へ通信できる必要があります
Azure Devops から Agent への疎通は不要ですが最低限 Agent -> Azure Devops のエンドポイントへの通信は必要になります

動作確認

azure-pipelines.yml を編集して使用する pool を指定しましょう

trigger:
  batch: true
  branches:
    include:
    - master

pool: test_pool

jobs:
- job: TestJob
  steps:
  - script: |
      echo "Hello, Azure Pipelines!"
      cat /etc/issue
      uname -a
    displayName: "Run My Command"

これでプロジェクトのパイプラインを確認すると問題なくジョブが実行されていることが確認できると思います

default の pool で進めた場合は default pool にパイプラインを実行する権限がないので権限を与えて上げるとパイプラインが実行し始めると思います

最後に

Azure Devops の Pipeline で独自のエージェントを構築してパイプライン実行してみました
Gitlab Runner に非常に似ている感じになります

Azure Devops は pool ないに Agent を追加する感じです
Gitlab では GroupRunner などがそれにあたりますがやや管理方法が異なる感じになります

また gitlab-ci.yml と azure-pipelines.yml との互換性は全くないのでそこは書き換えなどの処理が必要です

参考サイト

2024年3月8日金曜日

Azure Devops の pipeline 機能を使ってみる

Azure Devops の pipeline 機能を使ってみる

概要

前回 Azure Devops にソースコードを push してみました
今回は Pipeline 機能を使ってみます

環境

  • Azure Devops (2024/03/07 時点)
  • macOS 11.7.10

ブランチ作成

一応ブランチを作成し Pull request 形式でパイプライン用のファイル azure-pipelines.yml を作成します

  • git checkout -b feature/pipeline

azure-pipelines.yml の作成

今回は単純なコマンドを実行するパイプラインを作成します

  • vim azure-pipelines.yml
trigger:
- master

pool:
  vmImage: "ubuntu-latest"

jobs:
- job: TestJob
  steps:
  - script: |
      echo "Hello, Azure Pipelines!"
      cat /etc/issue
      uname -a
    displayName: 'Run My Command'

vmImage

Gitlab で言うところの Runner が pool になります
pool には Microsoft がデフォルトで用意している pool と独自で用意可能な pool があります

今回はデフォルトで用意されている pool にある vmImage を使います
デフォルトで使用可能な vmImage はこちらにあります

また

  • Project Settings -> Agent pools でも現在有効なプール (エージェント) が確認できます

push してみる

  • git add .
  • git commit -m "Add azure-pipelines.yml"
  • git push -u azure feature/pipeline

Pull Request を作成しマージする

Repos -> Pull requests に移動し p-r を作成しましょう
ブランチの「Create a pull request」から作成すると簡単です

タイトル、概要、タグ、レビュアー、紐づけるアイテムを設定します
パイプラインや Approvers などは設定できないいようです

内容を確認して「Complete」でマージします (実際はレビューなどして問題なければマージします

パイプラインを実行する

現状だと自動で実行されないのでとりあえず手動で実行します
左メニューから Pipelines を選択し「Create Pipeline」を選択します

Azure Repos Git を選択します

実行するジョブ (test) を選択します

azure-pipelines.yml の内容が表示されます
あとは右上の Run をクリックすれば OK です

なおパイプラインが失敗するとメールで通知してくれます

[error]No hosted parallelism has been purchased or granted. To request a free parallelism grant, please fill out the following form https://aka.ms/azpipelines-parallelism-request

というエラーが出る場合があります
これは無料枠の pool を使うのには申請が必要なために出ます
https://aka.ms/azpipelines-parallelism-request ここから無料枠の pool を使う申請ができるので名前やメールアドレス、組織名を入力すれば簡単に申請することができます

最後に

Azure Devops の Pipeline 機能を試してみました
パイプラインの機能自体は YAML ファイルを一つ追加するだけなので簡単に使えます
パイプラインの記法や機能のリファレンスは参考リンクにあります

無料枠の pool を使うには申請が必要なのでとりあえず検証したいだけであれば申請すると良いかなと思います (申請がすべて通るのかは不明
あとは自分のマシンを pool として登録することもできるのでマシンリソースに余裕があるのであれば自分のマシンを登録するのもありかなと思います

次回はそのあたりのセルフホステッド pool のやり方なども紹介できればなと思います

参考サイト

2024年3月7日木曜日

Azure Devops にソースコードを push する方法

Azure Devops にソースコードを push する方法

概要

Azure Devops を使ってみました
まずはプロジェクトを作成しコードを push するところまでやってみました

環境

  • Azure Devops (2024/03/07 時点)

事前準備

事前に Azure Devops の申込みとテスト用のプロジェクトの作成を行っておきましょう
基本は無料で範囲内で使用できるはずです

push してみる

まずは左メニューの「Repos」を選択します
Azure Devops の場合デフォルト画面はダッシュボードで Github の用にソースコードの管理画面ではないようです

Repos を選択するとリモートリポジトリ用の URL が表示されるので既存のリポジトリに設定を追加します
user01 の部分は適宜変更してください
また origin はすでに登録されているので azure というリモート名で登録します

  • git remote add azure https://user01@dev.azure.com/user01/test/_git/test

あとは azure に対して push するだけです

  • git push -u azure master

認証情報は

Azure のコンパネにログインするパスワードではないようです
個人用アクセストークン (PAT) を使って認証します

まずは右上の設定マークから「Personal access tokens」にアクセスします

すると新規トークン作成画面になるので「New Token」を選択します

トークンに名前を設定します
またトークンのアクセス範囲と期限を設定します
今回はフルアクセスで30日にしていますが好きなように変更してください
期限はカスタムでもっと伸ばすこともできます

作成されるとトークンが表示されるので必ずコピーしておきます
ここで画面を消してしまうともう二度と同じトークンを表示できません (再作成になります

作成が完了すると以下のようにトークンの一覧が表示されます
トークン作成後でも期限やスコープを編集することができます

改めて push してみる

作成したトークンを使って改めて push してみましょう
問題なく push できることが確認できると思います
今度は Repos を確認するとちゃんとソースコードの一覧が確認できます

またトークンが作成されるとメールに通知も届きます

最後に

Azure Devops に既存の git リポジトリを push してみました
認証が独自のトークンなのでそこだけ事前に作成しておく必要があります

次回は Pull Requests を作成してみます

2022年3月24日木曜日

Gitlab と連携する AzureAD にユーザを追加する方法

Gitlab と連携する AzureAD にユーザを追加する方法

概要

過去に Gitlab + AzureAD の連携方法を紹介しました
今回はユーザを AzureAD に追加する方法を紹介します

環境

  • Gitlab 14.5.4

1. ユーザの追加

ホーム -> 既定のディレクトリ -> ユーザー -> 新しいユーザー

で追加します
必須パラメータはすべて埋めましょう

2. エンタープライズアプリケーションにユーザを登録する

ホーム -> 既定のディレクトリ -> エンタープライズアプリケーション -> Azure AD SAML Toolkit -> ユーザーとグループ -> 割り当ての追加

先程追加したユーザを選択しましょう

3. ユーザのメールアドレスを設定する

登録したユーザを選択してメールアドレスを設定しましょう
Gitlab と連携する場合はメールアドレスの設定が必須になります

注意点

初回ログイン時にはパスワードを変更するように求められるので変更しましょう

2021年12月10日金曜日

Gitlab の SAML Groups 機能を試してみた

Gitlab の SAML Groups 機能を試してみた

概要

Gitlab の SAML Groups 機能は SAML Idp 側から送信される Groups 情報を元にログインの許可やユーザ属性の自動付与を行うことができます

今回は AzureAD を使って試してみました

環境

  • Gitlab 14.3.4-ee
  • AzureAD (20211126 時点)

Required Groups

Required Groups 機能はリスト内に含まれるグループ情報でなければログインできなくする機能です

gitlab.rb では以下のように設定します

gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_auto_link_saml_user'] = true
gitlab_rails['omniauth_providers'] = [
  {
    name: "saml",
    label: "AzureAdTest",
    groups_attribute: 'Groups',
    required_groups: ['Developers', 'Freelancers', 'Admins', 'Auditors'],
    args: {
      assertion_consumer_service_url: "https://your.gitlab.example.com/users/auth/saml/callback",
      idp_cert_fingerprint: "xxxx",
      idp_sso_target_url: "https://login.microsoftonline.com/xxxxxx/saml2",
      issuer: "https://your.gitlab.example.com",
      name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
    }
  }
]

まず groups_attribute で AzureAD 側から送信される「属性とクレーム」のクレーム名を指定します
そして required_groups を使って必須のグループ名を指定します
ここで指定されるグループ名が AzureAD から送信されない場合はログインエラーになります

AzureAD 側のクレーム設定は以下のとおりです
例えば Admins という属性を持っている場合はログインできます
ここで注意してほしいのは例え AzureAD 側で Admins を設定していても Gitlab 側の管理者グループに所属するわけではないという点です

もし管理者グループに自動で登録したい場合は required_groups ではなく admin_groups を使います

これで再度ログインしてみるとちゃんとログインできるのが確認できます
またどのグループにも属していないのが確認できると思います

External Groups

external_groups はリスト内に記載されているグループだった場合に Gitlab の External user フラグを自動的にオンにしてくれる機能です

gitlab.rb は以下のように記載します
先程 required_groups と記載していたところを external_groups に変更します

gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_auto_link_saml_user'] = true
gitlab_rails['omniauth_providers'] = [
  {
    name: "saml",
    label: "AzureAdTest",
    groups_attribute: 'Groups',
    external_groups: ['Freelancers'],
    args: {
      assertion_consumer_service_url: "https://your.gitlab.example.com/users/auth/saml/callback",
      idp_cert_fingerprint: "xxxx",
      idp_sso_target_url: "https://login.microsoftonline.com/xxxxxx/saml2",
      issuer: "https://your.gitlab.example.com",
      name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
    }
  }
]

AzureAD 側のクレームは Admins ではなく Freelancers が送信されるようにします

これでログインすると Gitlab の External user フラグが自動でオンになっているの確認できます

External user フラグがオンになっている場合はプロジェクトが作成できなかったり Public なプロジェクトしか見れなくなります

最後に

他には Administrator groups と Auditor groups があります
前者は自動で Gitlab の管理者グループに登録する機能で後者はリードオンリーユーザとして登録する機能になります

それぞれの機能は And 条件として使うことができます
なので必須のグループ名かつこのグループ名は Admin として登録するということが可能です

自動で特定の属性を付与したい場合には便利かもしれません

参考サイト

2021年11月27日土曜日

Gitlab + AzureAD + SAML 連携

Gitlab + AzureAD + SAML 連携

概要

Gitlab の OmniAuth Provider を使って Azure AD と SAML 連携してみました
AzureAD の oauth2 連携の記事はよく見るのですが SAML 連携はあまり見ない気がします

ポイントは AzureAD でエンタープライズアプリケーション「Azure AD SAML Toolkit」を作成する点です

環境

  • Gitlab 14.3.4-ee
  • AzureAD (20211126 時点)

AzureAD で Azure AD SAML Toolkit エンタープライズアプリケーションの作成

まずは AzureAD でエンタープライズアプリケーションを作成します
Azure ポータルにログインしたら「Azue Active Directory」を選択します

AzureAD のトップページに来たら左メニューの「エンタープライズアプリケーション」を選択します

「新しいアプリケーション」からエンタープライズアプリケーションを作成します

検索窓で「Azure Toolkit」で検索しましょう
すると「Azure AD SAML Toolkit」が表示されるので選択します
右ペインで名前を入力できるので好きな名前を入力して「作成」しましょう

エンドポイントの確認

エンタープライズアプリケーションは普通のアプリとしても登録されています
左メニューの「アプリの登録」からアプリの一覧を確認できます

アプリの詳細を選択して「エンドポイント」を選択すると SAML ログインに必要な URL が表示さます
「SAML-P サインオンエンドポイント」に記載されている URL をメモしておきましょう

シングルサインオンの設定

作成されたエンタープライズアプリケーションを選択し詳細画面にいきます
先程は「アプリの登録」でアプリを確認しましたがエンタープライズアプリケーションは左メニューの「エンタープライズアプリケーション」から確認できます

一覧から作成した Azure AD SAML Toolkit のエンタープライズアプリケーションを選択しましょう

シングルサインオンの設定にある「作業の開始」を選択します

そして SAML を選択します

1 番の「基本的なSAML構成」を「編集」します
右ペインに必要な情報を入力します

  • 識別子・・・GitlabのURL
  • 応答 URL・・・GItlabのURLのコールバックURL
  • サインオンURL・・・先程アプリの登録のエンドポイントで確認したURL

入力したら「保存」しましょう

シングルサインオンから必要な情報をメモ

3 番に「SAML 署名証明書」があります
ここの「拇印」をメモしておきましょう

email 属性の追加

2 番に「属性とクレーム」があります
Gitlab と SAML 連携する場合には必ず email or mail という属性がレスポンスに含まれている必要があります

編集を選択します

  • 名前・・・email
  • 名前空間・・・空
  • ソース・・・属性
  • ソース属性・・・user.mail

と入力し「保存」します

アプリにユーザを登録する

左メニューの「ユーザとグループ」を選択します まだユーザはいないので「ユーザまたはグループの追加」を選択します

好きなユーザやグループを登録しましょう
Gitlab からログインできるユーザはここでエンタープライズアプリケーションに紐付けたユーザまたはグループのみになります

gitlab.rb の修正

あとは gitlab.rb を編集します
OmniAuth の部分を編集します

記載する箇所を5箇所です

  • assertion_consumer_service_url・・・Gitlabのコールバック用のURL
  • idp_cert_fingerprint・・・先程確認した拇印
  • idp_sso_target_url・・・エンドポイントで確認したSAMLサインオンURL
  • issuer・・・GitlabのURL
  • label・・・ログイン時に表示される文言

あと任意で変更して良さそうな名は omniauth_block_auto_created_users になります
true にすると SAML 経由でログインしたユーザは自動で登録されずに Gitlab の Admin ユーザの承認を待ってからログインすることができます
false になっていれば自動で承認されて使えるようになります

gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_auto_link_saml_user'] = true
gitlab_rails['omniauth_providers'] = [
  {
    name: "saml",
    label: "AzureAdTest",
    args: {
      assertion_consumer_service_url: "https://your.gitlab.example.com/users/auth/saml/callback",
      idp_cert_fingerprint: "3番で確認した拇印",
      idp_sso_target_url: "アプリ登録のエンドポイントで確認したSAMLサインオンURL",
      issuer: "https://your.gitlab.example.com",
      name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
    }
  }
]

必要な箇所が修正できたら reconfigure を実行しましょう

動作確認

Gitlab にアクセスするとログインフォームの下の方に Azure AD でログインするためのボタンが設置されます

ボタンを押すと MS のログイン画面に遷移するのでここで先程登録したユーザやグループに属するユーザでログインしてみましょう

トラブルシューティング

422 でログインできない場合は email 属性がちゃんと設定されているか確認しましょう

最後に

AzureAD + Gitlab + SAML 認証を試してみました

一番わかりづらかったのはエンタープライズアプリケーションを作る点でした
普通のアプリケーションだと SAML の設定項目がなく oauth2 しかできなさそうなので注意しましょう

今回は「Azure AD SAML Toolkit」を使いましたがもしかするとそのうちエンタープライズアプリケーションの一覧に「Gitlab」が登場するかもしれません

また今回やらなかったこととして他の属性の連携 (name) やユーザの2authの対応などはやりませんでした
この辺りもできそうなので興味があれば調べてみると良いかもしれません

参考サイト