こんにちは。kuuです。
さくらのクラウドで外部の担当者にサーバ操作を依頼する場合や、研修・演習用のサーバを提供する場合、
プロジェクト全体の操作権限を渡すのは避けたいことがあります。
さくらのクラウドには、指定したサーバ1台だけを操作できる「シングルサーバコントロールパネル」が用意されています。
シングルサーバコントロールパネルでは、さくらのクラウドユーザーを作成せず、
専用のAPIキーを使用して対象サーバの情報閲覧、電源操作、リモートコンソール操作を許可できます。
今回はシングルサーバAPIキーを発行し、実際に以下の点を確認します。
- 指定したサーバ1台だけが表示されるか
- 通常のコントロールパネルと表示される項目に違いがあるか
- サーバのシャットダウンと起動ができるか
- リモートコンソールを利用できるか
- アクセスレベルを「アクセス不可」にすると利用できなくなるか
シングルサーバコントロールパネルとは
シングルサーバコントロールパネルは、指定したサーバ1台だけを操作できる専用のコントロールパネルです。
契約者側がシングルサーバAPIキーを発行し、利用者はアクセストークンとアクセストークンシークレットを使用して専用画面へログインします。
クラウドユーザーやプロジェクトを追加で作成する必要がなく、保守委託先によるメンテナンスや、学校・研修における演習用サーバの提供などが想定されています。
シングルサーバコントロールパネルでは、主に以下の操作が許可されています。
- サーバ名、リソースID、プランなどの情報閲覧
- アクティビティグラフの閲覧
- サーバの電源操作
- リモートコンソール操作
詳しい仕様については、以下の公式マニュアルをご確認ください。
シングルサーバコントロールパネル｜さくらのクラウド マニュアル
通常のアクセスレベルとの違い
複数のサーバやディスク、ネットワークなども操作してもらう場合は、クラウドユーザーを作成してアクセスレベルを設定する方法が適しています。
操作対象をサーバ1台に限定したい場合は、シングルサーバコントロールパネルの方が目的に合っています。
| 比較項目 | シングルサーバコントロールパネル | クラウドユーザーとアクセスレベル |
|---|---|---|
| 操作対象 | 指定したサーバ1台 | 権限を付与したプロジェクト内 |
| 認証方法 | アクセストークンとシークレット | 会員ID、ユーザーコード、パスワード |
| ユーザー作成 | 不要 | 必要 |
| 主な操作 | 情報閲覧、電源、コンソール | アクセスレベルに応じたリソース操作 |
| 向いている用途 | 1台限定の保守、研修、演習 | 複数リソースを扱う継続的な運用 |
クラウドユーザーのアクセスレベルについては、以下の記事で検証しています。
今回の検証環境
今回は、前回のアクセスレベルとサービスポリシーの検証で作成した policy-test-server を引き続き使用します。
同じプロジェクト内には比較用の別サーバも存在しているため、シングルサーバコントロールパネルから対象外のサーバが表示されるかも確認します。
シングルサーバAPIキーを発行する
まず、さくらインターネット会員IDでクラウドコントロールパネルへログインします。
対象サーバが存在するプロジェクトを選択し、左側のメニューから「APIキー」を開きます。
「APIキーの作成」をクリックします。
APIキーの作成画面が表示されるので、各項目を入力します。
今回入力した内容は以下のとおりです。
| 項目 | 設定例 |
|---|---|
| APIキーの種類 | シングルサーバAPIキー |
| APIキー名 | シングルサーバテスト |
| 説明 | policy-test-server用 |
| アクセスレベル | 電源操作 |
| 紐付け先サーバ | 石狩第3ゾーン／policy-test-server |
入力内容を確認し、「作成」をクリックします。
APIキーが作成され、アクセストークンとアクセストークンシークレットが発行されました。
アクセストークンシークレットを取得できるのは、APIキーの作成時のみです。
作成画面を閉じると再度取得できないため、この時点でコピーするか、CSV形式でダウンロードして保管します。
アクセストークンシークレットを紛失した場合は、APIキーを再発行する必要があります。
アクセストークンとアクセストークンシークレットは、シングルサーバコントロールパネルへログインするための認証情報です。実際に利用する場合は、第三者へ漏えいしないよう安全に管理する必要があります。
APIキーの作成や管理については、以下の公式マニュアルもあわせてご確認ください。
シングルサーバコントロールパネルへログインする
利用者側は、以下の専用URLへアクセスします。
先ほど発行したアクセストークンとアクセストークンシークレットを入力してログインします。
ログインすると、APIキーに紐付けた policy-test-server の情報が表示されました。
シングルサーバコントロールパネルで表示される範囲
通常のコントロールパネルでは、同じプロジェクト内の policy-test-server と テスト
サーバ が表示されています。
シングルサーバコントロールパネルでは、APIキーに紐付けた policy-test-server だけが表示されました。
また、サーバ情報、NIC情報、アクティビティ、コンソールは確認できますが、
ディスク、ISOイメージ、シンプル監視などの項目は表示されませんでした。
シンプル監視については、通常のコントロールパネルから以下の記事を参考に設定しました。
シンプル監視を設定後もシングルサーバコントロールパネルには表示されませんでした。
この結果から、シングルサーバコントロールパネルでは、操作対象がサーバ1台に限定されるだけでなく、表示・操作できる機能も限定されていることが確認できました。
電源操作を確認する
続いて、シングルサーバコントロールパネルからサーバの電源操作を行います。
まず、「シャットダウン」を実施します。
シャットダウンが成功し、サーバのステータスが DOWN になりました。
続いて、「起動」を選択します。
起動処理が成功し、サーバのステータスが UP に戻りました。 シングルサーバコントロールパネルから、
対象サーバのシャットダウンと起動を行えることが確認できました。
リモートコンソールを確認する
続いて、「コンソール」を選択します。
対象サーバのリモートコンソールが開き、OSのログイン画面が表示されることを確認できました。
なお、シングルサーバAPIキーはコントロールパネルへのログインに使用する認証情報です。
OSへログインする場合は、OS側のユーザー名やパスワードなどが別途必要になります。
コンソールの仕組みやSSHとの違いについては、以下の記事で解説しています。
さくらのクラウドの「コンソール」はいつ使う？SSHとの違いと活用シーンについて
アクセスレベルを「アクセス不可」に変更する
続いて、シングルサーバAPIキーのアクセスレベルを変更します。
通常のクラウドコントロールパネルから対象のAPIキーを開き、アクセスレベルを「電源操作」から「アクセス不可」へ変更します。
「アクセス不可」を選択し、「保存」をクリックします。
APIキー一覧から、アクセスレベルが「アクセス不可」になったことを確認しました。
この状態で、ログインしていたシングルサーバコントロールパネルを再読み込みすると、
以下のログインエラーが表示されました。
また、APIキーの詳細画面には、以下のメッセージが表示されました。
シングルサーバコントロールパネルにアクセスするには電源操作のアクセスレベルが必要です。
アクセスレベルが「アクセス不可」の場合は、シングルサーバコントロールパネルへアクセスできないことが確認できました。
アクセスレベルを「電源操作」に戻す
続いて、APIキーのアクセスレベルを「アクセス不可」から「電源操作」へ戻します。
設定の反映後、同じアクセストークンとアクセストークンシークレットを使用して、
再びシングルサーバコントロールパネルへアクセスできました。
APIキーやアクセストークンシークレットを再発行する必要はありませんでした。
この結果から、一時的に利用を停止したい場合はアクセスレベルを「アクセス不可」に変更し、
再び利用を許可する場合は「電源操作」に戻す、という使い分けができます。
今後使用する予定のないAPIキーについては、「アクセス不可」のまま残しておくのではなく、不要になった時点で削除しておくことを推奨します。
おわりに
今回は、さくらのクラウドのシングルサーバコントロールパネルを使用し、指定したサーバ1台だけの操作を許可できるか検証しました。
シングルサーバAPIキーを利用すると、クラウドユーザーを新しく作成せず、対象サーバの情報閲覧、電源操作、リモートコンソール操作を許可できます。
実際に確認したところ、通常のコントロールパネルでは複数のサーバが表示されていましたが、シングルサーバコントロールパネルでは、APIキーに紐付けたサーバ1台だけが表示されました。
また、ディスクやISOイメージ、シンプル監視などのタブや、クローン、プラン変更、サーバ削除などの操作項目は表示されませんでした。
APIキーのアクセスレベルを「アクセス不可」に変更すると利用できなくなり、「電源操作」へ戻すと、APIキーを再発行せずに再度アクセスできました。
サーバ1台だけの保守や研修・演習環境を提供する場合には、プロジェクト全体の操作権限を渡さずに済む方法として利用できます。
複数のリソースを継続して操作してもらう場合は、クラウドユーザーとアクセスレベルを使用する方法もあわせてご検討ください。
この記事を書いた人
