はじめに
職場でOpenshift構築後の結合テストを経験することがありました。
初めての経験だったので、今回の経験を備忘録がてらまとめます。
記事のボリューム的にOpenshiftというよりも、認証と認可の話になっておりますが、ご容赦ください。
構成
Openshiftコンソールへのアクセスは
1:踏み台サーバにRDP
2:URLをブラウザに打ち込んでログイン
CLIでのOpenshiftへのアクセスは
1:踏み台サーバにRDP
2:踏み台サーバから作業用サーバにSSH
前提知識
htpasswdとは？
ホームページなどで、以下のようなポップアップが現れて、特定の人にしかアクセスできないページがあるとします。
まずこのような認証をBasic認証といいます。
他にもDigest認証やForm認証というものもありますが、今回は深掘りしません。
以下のリンクで相違点についてわかりやすく説明されています。
今回実装したいのはBasic認証です。
そのために必要になるのが、「.htaccess」と「.htpasswd」いうファイルです。
ざっくり説明すると以下のようになります
.htaccess：認証パターンや（今回はBasic).htpasswdファイルの場所を指定する
.htpasswd：Basic認証のログイン情報（IDとパスワード）を記載するファイルです
認証と認可とは？
言葉の定義としては、以下になります。
認証(Authentication)
相手が誰であるかを確認することで、以下の三要素に分類されます。
Inherence factor:生体認証など
Possession factor:身分証など
Knowledge factor:パスワードなど
イメージとしては、証明書の確認です。
なので、認証されたからといって何かが起きるわけではありません。
認可(Authorization)
特定の条件に対して、リソースアクセス権限を与えることです。
イメージとしては、切符の発行です。
そのため、切符が発行されたとしても、持ち主が誰であるか関係ありません。
また、仮に誰かから切符を譲り受けたとしても、電車になることはできますね。
注意点
券売機の例に例えると、
1：券売機で、本人確認【認証】
2：券売機で、チケットを発行【認可】
3：係員が、チケットを確認して入場を許可する
となるので、あくまで係員の方がチケットを確認しているのは、認可によって与えられた権利を検証しているだけです。
今回券売機に例えたように、現実世界では認証と認可がまとめて実施されることが多いです。
認証と認可はお気に入りなので、少し深掘りします。
オフィスで、一旦IDとパスワードが認証されると、様々なサービスにアクセスできるといったことがあるかと思います。
これにはSAML認証と呼ばれる認証プロセスが使用されています。
ネットワーク管理者などは、SAMLを利用して一元的にユーザー管理が可能です。
IdPとは？
上記SAML認証におけるクラウドサービスにアクセスするユーザの認証情報を保存、管理するサービスのことを指します
これに対してOAuthといった別の仕組みも存在します
わかりやすい例が有効なGoogleアカウントもつユーザが同じ資格情報を使用してさまざまなデータを活用できる。といったものです
つまり、OAuthではユーザ認証はGoogleに任せているということになりますね。
こちらの記事ではOAuthとAPIの関わりについて、より深く説明がされています
以下のリンクでSAMLとOAuthの違いについて説明されています。
作業概要
では今から本旨に移ります。
今回は構築されたOpenshift環境に対して、以下を結合テストの一部として実施しました。
・踏み台サーバからWEBコンソールにアドミンユーザでログインできるか
・踏み台サーバからCLIでOpenshiftにログインできるか
・プロジェクトの作成及び削除ができるか
・ユーザの作成及び削除ができるか
今回の記事ではユーザの作成及び削除ができるかにフォーカスしてまとめていきます
htpasswdファイルのSecret作成
以下コマンドでルートディレクトリ以下に、htpasswdファイルを作成します。
htpasswd -c -B -b ~/htpasswd admin hoge
Adding password for user admin
コマンドの意味の詳細はこちらのリンクを確認ください
今回は、ユーザで名がadminでパスワードがhogeというユーザを作成します。
作成されたhtpasswdファイルをcatコマンドで確認すると、エンコードされたユーザ名とパスワードが記載されています。
htpasswdファイルを格納したSecretを作成し、Openshiftに登録
※事前にOpenshiftにログインしておく必要がにあります
oc create secret generic myusers --from-file oc create secret generic htpass-secret --from-file=htpasswd=./users.htpasswd -n openshift-config
Basic認証は、htaccessとhtpasswdが対になって実現でます。
解釈としては、サーバ側にhtpasswdを登録するが良いかと思っています。
以下コマンドでopenshift-configの中にシークレット（IDとパスワード）が保存されていることが確認できます。
c get secrets -n openshift-config
Identity Providerに今回作成したhtpasswdを追加
現在のOAuth設定コンソール画面の、Administration > Cluster Settings > Global Configuration > OAuth から確認することができます。
CLIからも確認→実施が可能ですが、今回はGUIで実施します。
1:作業用サーバから、htpasswdファイルを踏み台サーバに SSH SCPで転送
※権限の変更が必要になるかもしれません
2:Webコンソールに入り、 「管理」-「クラスター設定」-「OAuth」-「Identity Provider」-「Add」から[htpasswd]を選択し、保存されたusers.htpasswdをアップロード
3:Webコンソールから、「Identity Provider」に「htpasswd」が登録されていることを確認
ポリシーの設定
以下コマンドで、今回追加したユーザーにアドミンポリシーを追加
oc adm policy add-cluster-role-to-user cluster-admin <ユーザ名>
ログインの確認
CLI
oc login https://api.<clusterName>.<baseDomain>.local:6443 -u <ユーザ名>
GUI
現在ログインしているユーザからログアウトし、今回作成したユーザでログインする
以上で、ユーザの作成手順は終了です。
ユーザ削除としては、
・htpassに格納されているsecret情報を入手
・その編集（今回は削除）
・編集されたhtpasswdファイルを更新する
というステップで実行します。
$ oc get secret htpass-secret -o jsonpath={.data.htpasswd} -n openshift-config | base64 -d > users.htpasswd
$ htpasswd -D users.htpasswd <ユーザ名>
$ oc create secret generic htpass-secret --from-file=htpasswd=users.htpasswd --dry-run=client -o yaml -n openshift-config | oc replace -f -
$ oc delete user <ユーザ名>
$ oc delete identity htpasswd:<ユーザ名>
以上です。
参考
環境
確認取れ次第記載します
終わりに
今回はOpenshiftのユーザー作成を通じて、認証と認可について深堀することができました。
普段何気なく使用しているオフィスの認証も、仕組みを理解すると面白いですね。
今後とも、”とりあえず使用しているが、仕組みを理解していないもの”の深堀を続けていければと思っております。