日本語フォーラム

Aruba の無線 LAN / ゲートウェイ製品の強みのひとつが、ロールベースのアクセス制御 (Role-Based Access Control) です。ユーザーがネットワークに接続した際、認証結果に応じて「社員ロール」「ゲストロール」「IoT ロール」といった Role を動的に付与し、アクセスできるリソースをきめ細かく制御できます。たとえば「社員は社内システムへのアクセスは許可するが、管理セグメントへの SSHなどのプロトコルは禁止する」といった設定が、デバイス種別や認証方式を問わず一元的に管理できます。

AOS8 → AOS10 への移行で何が変わったか

従来の AOS8 環境では、この Role/ACL の設定は CLI で行うのが一般的でした。

netdestination restricted-network
  network 172.16.100.0 255.255.255.0

ip access-list session restricted-policy
  userrole employee alias restricted-network svc-ssh deny
  userrole employee any any permit

user-role employee
  access-list session restricted-policy
  access-vlan 100

AOS8 に慣れた方ならこの記法はシンプルで直感的に感じられるはずです。

AOS10 / Central への移行に伴い、設定インターフェースは CLI 中心から GUI ベース（Web UI） へと移行しました。
Central の Web UI は視覚的でわかりやすく、日々の運用監視や基本設定には適しています。一方で、複雑な ACL ルールを多数のロールに対して適用したい場合や、大規模環境で同じ設定を繰り返し展開したい場合には、GUI を一画面ずつ操作する方法は少し手間がかかることもあります。

API を使う理由

そこで注目したいのが Central の Configuration API です。

API を使うと以下のことが可能になります：

• 大量の Role/ACL を一括で設定・変更 - スクリプトで繰り返し処理できるため、テナント全体に同じ Policy を展開する際の工数を大幅に削減できます
• 設定の再現性・バージョン管理 - JSON ファイルとして設定を保持できるため、Git 等でバージョン管理が可能です
• カスタム UI との統合 - 自社の管理ポータルや ITSM ツールから直接 Aruba Central の Role 設定をトリガーすることができます

実際の運用では、要件にあったスクリプト（Python / Node.js 等）やカスタム Web UI から API を呼び出す形になると思いますが、まず「どの API を使えばよいか」を理解するための入門として、ここでは Postman Collection を活用した手順を紹介します。

Central API の Role / Policy 設定モデル

CLI の設定は「上から順に読む」フラットな命令型でしたが、Central API は オブジェクト指向の宣言型 です。それぞれのリソースが独立した API エンドポイントとして存在し、組み合わせて Role を構成します。

CLI との対応関係

ここではAPIだけにフォーカスして説明しています。
Central の Policy 設定に関しては以下のドキュメントでも解説されてい流のでそちらも参照下さい。

Central Policy Configuration

設定フロー

実際の API 呼び出しの大まかな流れは以下の通りです。

1. GLP 認証 - HPE GreenLake Platform (GLP) の SSO でアクセストークンを取得します。New Central の API gateway とは別の sso.common.cloud.hpe.com が Token エンドポイントです
2. Net Group 作成 - 宛先 IP グループを /net-groups API で作成します（/object-groups ではないことに注意）
3. Role 作成 - Policy より先に作成します
4. Policy 作成 - POLICY_TYPE_SECURITY タイプで、3 つの Policy を作成します。Policy A（特定の通信を Deny）、Policy B（特定の宛先への通信を Deny）、Policy C（それ以外を全て Permit する catch-all）の順で評価されます
5. Policy Group への登録 - テナントに 1 つ存在する共有リストに PATCH で追記します
6. Config Assignment - Role と各 Policy を対象 Scope に割り当てます。Role と Policy はそれぞれ別の POST が必要です

注意点は、Policy Group への登録が必要な点です。
これを行わないと、Centralの内部的にPolicyを作成しただけになり、UIへPolicyが反映されません。
理由は、Policyの順序（UIの"Role based Policies"で確認できる順序）が、そのままPolicyを実行する順序になり、順序の決定はとても重要です。
この順序の反映が、上記ステップ5のPolicy Groupへの登録で実施されます。

Postman Collection について

本記事で説明した API の呼び出し手順を Postman Collection としてまとめました。

GitHub リポジトリ: aruba-central-role-postman

Collection の構成

• STEP 0 - GLP 認証・トークン取得（自動でEnvironment変数に保存）
• STEP 0.5 - Scope Discovery（scope-id を調べるための GET 集）
• STEP 1〜2 - Net Group 作成
• STEP 3a/3b - Role 作成（新規 POST / 既存 PATCH）
• STEP 4a/4b/4c - Policy A/B/C 作成
• STEP 5a/5b - Policy Group への登録（GET → PATCH）
• STEP 6a〜6d - Role と各 Policy を Scope へ割り当て（AP / GW 両方）
• STEP 7〜9 - 確認 (GET)
• STEP 10 - クリーンアップ（逆順 DELETE）

なんとなくの設定フロー図です。参考まで。

使い方

• Postman に Collection と Environment テンプレートをインポート
• Environment の以下の変数を記入：
  • baseUrl - Central UI → Menu > API Gateway で確認
  • client_id / client_secret - GLP Portal → API Client Management で発行
  • scopeId - STEP 0.5 を実行して取得
• STEP 0 からを順に実行
• STEP 10 は設定削除用のAPI一覧です。フォルダで"Run"すればいっきに削除してくれます

Role 名・IP アドレス・VLAN・適用するサービス（svc-ssh 等）はすべて Collection Variables として外出しされており、Postman の Variables タブから変更するだけで別のシナリオに再利用できるようになっています。
Policy/RoleをAP/Gatewayにアサインする時のScope IDの設定を忘れないようにして下さい。Scope IDは環境によって変わりますので、必ず Step 0.5 で確認して設定する必要があります。

最後に

Central の Configuration API は、大規模環境での Role/ACL 管理を効率化する大きな可能性を持っています。
このPostman Collection はあくまでAPIの動きを確認するだけにとどまっていますが、
これを参考に、独自のページで設定を簡素化することも、今の生成AIを使えば比較的容易にできると思います。
こんなの作った！というものがあれば、是非共有していただけると嬉しいです。

また、今回紹介した Postman Collection はあくまで個人で作成したものであり、HPE がサポートするものではありません。利用は自己責任でお願いします。
実際の本番環境への適用に際しては、十分なテストと検証を行った上でご利用ください。
何かフィードバックや気づいた点があれば、このAirheads CommunityやGitHub の Issue や PR でご連絡いただけると嬉しいです。

本記事は個人の調査・検証に基づいた内容です。API の仕様は予告なく変更される場合があります。