はじめに
リポジトリURI: https://github.com/eirblaze/dsc3_windows_ssh_server
本記事では、DSC v3 を使って Windows 上に SSH サーバを宣言的に構成する最小実装を紹介します。
スキーマ準拠の JSON、get/test/set の構成管理、Windows Firewall の正規化挙動など、
実践的なノウハウをまとめています。
ひとまず、 windows 環境で宣言的構成を実験したい半面、 Windows の構成管理は PowerShell や GPO が中心で、宣言的構成の事例はまだ少ないと思い、作成に至りました。
今回、DSC v3 を使って Windows 上に SSH サーバを構成する最小実装を作成し、 GitHub に公開したので紹介します。
補足: DSC v3 について
DSC v3 は PowerShell チームが開発している次世代の構成管理フレームワークで、
JSONベースの宣言的構成と get/test/set のシンプルな操作モデルが特徴です。
インストール: https://learn.microsoft.com/ja-jp/powershell/dsc/overview?view=dsc-3.0 の内容をもとに、winget install コマンドでインストール、または、 https://github.com/PowerShell/DSC から、最新の DSC をインストールします。
リポジトリの概要
DSC v3(Appx 版)は DISM API を使うリソースをサポートしないため、
OptionalFeatureList による OpenSSH.Server の導入はできません。
そのため、今回は以下の構成を宣言的に管理しています。
- sshd サービスの起動状態
- Windows Firewall の SSH ルール
構成の流れ
- 現在の状態を取得(get)
- desiredState との差分を検出(test)
- 差分を適用(set)
- 再度 test して一致を確認
ディレクトリ構成
configs/ssh-server.dsc.jsonscripts/resource.get.ps1scripts/resource.test.ps1scripts/resource.set.ps1
get / test / set の 3 スクリプトで構成のライフサイクルを管理しています。
JSON の宣言的構成
{
"resources": [
{
"resource": "Microsoft.Windows/Service",
"input": {
"name": "sshd",
"startType": "Automatic",
"status": "Running"
}
},
{
"resource": "Microsoft.Windows/FirewallRuleList",
"input": {
"rules": [
{
"name": "OpenSSH-Server-In-TCP",
"direction": "Inbound",
"protocol": 6,
"localPorts": "22",
"action": "Allow",
"enabled": true,
"profiles": ["Domain", "Private", "Public"]
}
]
}
}
]
}
最新版は GitHub リポジトリをご利用ください。
Service と FirewallRuleList はどちらも “スキーマに完全準拠した input” を要求します。
特に FirewallRuleList は rules が配列である点が重要です。
以下の 「スキーマ確認方法」 から、確認できます。
スキーマ確認方法
OptionalFeatureList のスキーマ確認
dsc resource schema --resource Microsoft.Windows/OptionalFeatureList
Service のスキーマ確認
dsc resource schema --resource Microsoft.Windows/Service
FirewallRuleList のスキーマ確認
dsc resource schema --resource Microsoft.Windows/FirewallRuleList
実行例 (pwoershell 管理者権限)
それぞれ以下のようになります。
現在の構成を取得: ./scripts/resource.get.ps1
> ./scripts/resource.get.ps1
Getting resource: Microsoft.Windows/Service
actualState:
name: sshd
displayName: OpenSSH SSH Server
description: SSH protocol based service to provide secure encrypted communications between two untrusted hosts over an insecure network.
_exist: true
status: Running
startType: Automatic
executablePath: C:\WINDOWS\System32\OpenSSH\sshd.exe
logonAccount: LocalSystem
errorControl: Normal
Getting resource: Microsoft.Windows/FirewallRuleList
actualState:
rules:
- name: OpenSSH-Server-In-TCP
protocol: 6
localPorts: '22'
remotePorts: '*'
localAddresses: '*'
remoteAddresses: '*'
direction: Inbound
action: Allow
enabled: true
profiles:
- All
interfaceTypes:
- All
edgeTraversal: false
現在の構成と、予定される構成の差分を取得し、検証する ./scripts/resource.test.ps1
> ./scripts/resource.test.ps1
Testing resource: Microsoft.Windows/Service
desiredState:
name: sshd
startType: Automatic
status: Running
actualState:
name: sshd
displayName: OpenSSH SSH Server
description: SSH protocol based service to provide secure encrypted communications between two untrusted hosts over an insecure network.
_exist: true
status: Running
startType: Automatic
executablePath: C:\WINDOWS\System32\OpenSSH\sshd.exe
logonAccount: LocalSystem
errorControl: Normal
inDesiredState: true
differingProperties: []
Testing resource: Microsoft.Windows/FirewallRuleList
desiredState:
rules:
- name: OpenSSH-Server-In-TCP
direction: Inbound
protocol: 6
localPorts: '22'
action: Allow
enabled: true
profiles:
- Domain
- Private
- Public
actualState:
rules:
- name: OpenSSH-Server-In-TCP
protocol: 6
localPorts: '22'
remotePorts: '*'
localAddresses: '*'
remoteAddresses: '*'
direction: Inbound
action: Allow
enabled: true
profiles:
- All
interfaceTypes:
- All
edgeTraversal: false
inDesiredState: false
differingProperties:
- rules
Windows Firewall はルールを内部的に正規化するため、
DSC v3 の desiredState と actualState に、上記のような差分が出る場合があります。
これは仕様であり、構成は正しく適用されています。
構成を設定する: ./scripts/resource.set.ps1
> ./scripts/resource.set.ps1
Setting resource: Microsoft.Windows/Service
beforeState:
name: sshd
displayName: OpenSSH SSH Server
description: SSH protocol based service to provide secure encrypted communications between two untrusted hosts over an insecure network.
_exist: true
status: Running
startType: Automatic
executablePath: C:\WINDOWS\System32\OpenSSH\sshd.exe
logonAccount: LocalSystem
errorControl: Normal
afterState:
name: sshd
displayName: OpenSSH SSH Server
description: SSH protocol based service to provide secure encrypted communications between two untrusted hosts over an insecure network.
_exist: true
status: Running
startType: Automatic
executablePath: C:\WINDOWS\System32\OpenSSH\sshd.exe
logonAccount: LocalSystem
errorControl: Normal
changedProperties: []
Setting resource: Microsoft.Windows/FirewallRuleList
beforeState:
rules:
- name: OpenSSH-Server-In-TCP
protocol: 6
localPorts: '22'
remotePorts: '*'
localAddresses: '*'
remoteAddresses: '*'
direction: Inbound
action: Allow
enabled: true
profiles:
- All
interfaceTypes:
- All
edgeTraversal: false
afterState:
rules:
- name: OpenSSH-Server-In-TCP
protocol: 6
localPorts: '22'
remotePorts: '*'
localAddresses: '*'
remoteAddresses: '*'
direction: Inbound
action: Allow
enabled: true
profiles:
- All
interfaceTypes:
- All
edgeTraversal: false
changedProperties: []
今後の展望
- sshd_config の宣言的管理
- 鍵認証の構成
- GitOps 化(GitHub Actions)
- OptionalFeatureList が使える DSC v3 への移行
- Windows の構成管理を体系化する
ただし、これらはあくまで windows 管理の未来を見据えた実験的な試みにとどめ、メインストリームはLinux中心のクラウドネイティブで構成されたモノレポリポジトリとして別枠で構成予定。
「宣言的」について補足
Windows の構成管理を宣言的に扱う事例はまだ少なく、
DSC v3 を使った実践的な構成管理は今後さらに価値が高まると考えています。
宣言的構成では「状態の差分」を扱うため、
“何をすべきか” ではなく “何が違うか” を中心に管理できます。
宣言的構成とは何か(DSCv2 → DSCv3 の進化)
DSC v2 以前は、PowerShell のスクリプトで「どうやって状態に到達するか」を記述する
命令的(Imperative)構成が中心でした。
例:
- サービスを起動する
- レジストリを書き換える
- ファイアウォールを追加する
これらは「手続き」を書く必要があり、
構成の再現性や差分管理が難しいという課題がありました。
DSC v3 はこれを 宣言的(Declarative)構成に再設計しています。
宣言的構成では、
「最終的にどういう状態であってほしいか」だけを書く。
例:
"status": "Running"
"startType": "Automatic"
すると DSC v3 が:
- 現在の状態を取得(get)
- 差分を検出(test)
- 必要な変更だけ適用(set)
という一連の流れを自動で行います。 docker compose や Ansible に近い、 「抽象化の向こうに、手続きを追いやる」 発想です。
つまり:
「状態を宣言するだけで、手続きはすべて DSC が判断する」
→ これが宣言的構成の本質です。
宣言的構成のメリット(SRE/MLOps の文脈)
SRE や MLOps の現場では、
「構成の再現性」「差分管理」「自動化」「GitOps」が重要になります。
宣言的構成はこれらと非常に相性が良い。
✔ べき等性 ( Idempotency: 同じ操作を何度繰り返しても結果が変わらない性質 )
同じ構成を何度 apply しても、状態が安定する。
✔ 差分管理が容易
test で「どこが違うか」が明確に出る。
✔ GitOps と親和性が高い
構成が JSON なので、Git で管理しやすい。
✔ CI/CD と統合しやすい
GitHub Actions で dsc resource set を流すだけで構成が適用できる。
Terraform との親和性
Terraform も宣言的構成であり、
「状態を宣言 → 差分を検出 → apply」という流れは DSC v3 と同じです。
それぞれの役割は、
- Terraform (クラウドの IaC) → クラウドの状態管理
- DSC v3 (OS の IaC) → Windows OS の状態管理
となり、オンプレ・クラウド混在環境でも、インフラから OS までを一貫して宣言的に扱えるようになります。
構成の実態は json や YAML であり、 Git でも管理できます。特に SRE/MLOps では、このような 環境全体を宣言的に管理する という強力なアーキテクチャが役に立つでしょう。
まとめ:宣言的構成は Windows 管理の未来
Windows の構成管理は長らく命令的モデルが中心でしたが、
DSC v3 によって 宣言的構成の時代が始まっています。
- べき等性
- 差分管理
- GitOps
- IaC
- SRE/MLOps との親和性
これらを満たす構成管理は、
今後の Windows 運用において確実に価値が高まると考えています。
今回の SSH サーバ構成はその最小実装ですが、
DSC v3 を使った Windows 管理は、今後の IaC の重要な選択肢になるかもしれません。