Openshiftでユーザ作成及び削除を実施してみた

## はじめに
職場でOpenshift構築後の結合テストを経験することがありました。
初めての経験だったので、今回の経験を備忘録がてらまとめます。
記事のボリューム的にOpenshiftというよりも、認証と認可の話になっておりますが、ご容赦ください。
## 構成
Openshiftコンソールへのアクセスは
1:踏み台サーバにRDP
2:URLをブラウザに打ち込んでログイン

CLIでのOpenshiftへのアクセスは
1:踏み台サーバにRDP
2:踏み台サーバから作業用サーバにSSH

## 前提知識
###### htpasswdとは？
ホームページなどで、以下のようなポップアップが現れて、特定の人にしかアクセスできないページがあるとします。

<img width="300" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2666121/422657c5-e1c5-54d0-0237-480675377938.png">

まずこのような認証を**Basic認証**といいます。
他にも**Digest認証**や**Form認証**というものもありますが、今回は深掘りしません。
以下のリンクで相違点についてわかりやすく説明されています。

https://medium-company.com/http%E8%AA%8D%E8%A8%BC%E6%96%B9%E6%B3%95%E3%81%AE%E7%A8%AE%E9%A1%9E%E3%81%A8%E9%81%95%E3%81%84/

今回実装したいのは**Basic認証**です。
そのために必要になるのが、「.htaccess」と「.htpasswd」いうファイルです。
ざっくり説明すると以下のようになります
**.htaccess**：認証パターンや（今回はBasic).htpasswdファイルの場所を指定する
**.htpasswd**：Basic認証のログイン情報（IDとパスワード）を記載するファイルです

https://www.itra.co.jp/webmedia/basic_authentication.html

https://www.futomi.com/lecture/htaccess/htpasswd.html

###### 認証と認可とは？
言葉の定義としては、以下になります。

**認証(Authentication)**
相手が誰であるかを確認することで、以下の三要素に分類されます。

Inherence factor:生体認証など
Possession factor:身分証など
Knowledge factor:パスワードなど

イメージとしては、証明書の確認です。
なので、認証されたからといって何かが起きるわけではありません。


**認可(Authorization)**
特定の条件に対して、リソースアクセス権限を与えることです。
イメージとしては、切符の発行です。
そのため、切符が発行されたとしても、持ち主が誰であるか関係ありません。
また、仮に誰かから切符を譲り受けたとしても、電車になることはできますね。

**注意点**
券売機の例に例えると、

1：券売機で、本人確認【認証】
2：券売機で、チケットを発行【認可】
3：係員が、チケットを確認して入場を許可する

となるので、**あくまで係員の方がチケットを確認しているのは、認可によって与えられた権利を検証しているだけです**。
今回券売機に例えたように、現実世界では認証と認可がまとめて実施されることが多いです。

https://dev.classmethod.jp/articles/authentication-and-authorization/

認証と認可はお気に入りなので、少し深掘りします。
オフィスで、一旦IDとパスワードが認証されると、様々なサービスにアクセスできるといったことがあるかと思います。
これには**SAML認証**と呼ばれる認証プロセスが使用されています。
ネットワーク管理者などは、SAMLを利用して一元的にユーザー管理が可能です。

https://boxil.jp/mag/a2950/

###### IdPとは？
上記SAML認証におけるクラウドサービスにアクセスするユーザの認証情報を保存、管理するサービスのことを指します

https://www.splashtop.co.jp/knowhow/28/


これに対して**OAuth**といった別の仕組みも存在します
わかりやすい例が有効なGoogleアカウントもつユーザが同じ資格情報を使用してさまざまなデータを活用できる。といったものです
つまり、**OAuthではユーザ認証はGoogleに任せている**ということになりますね。

https://www.tdk.com/ja/tech-mag/knowledge/147

こちらの記事ではOAuthとAPIの関わりについて、より深く説明がされています

https://qiita.com/TakahikoKawasaki/items/e37caf50776e00e733be


https://boxil.jp/mag/a3207/


以下のリンクでSAMLとOAuthの違いについて説明されています。

https://i.moneyforward.com/resources/saml_sso

https://www.okta.com/jp/identity-101/saml-vs-oauth/


## 作業概要
では今から本旨に移ります。
今回は構築されたOpenshift環境に対して、以下を結合テストの一部として実施しました。

・踏み台サーバからWEBコンソールにアドミンユーザでログインできるか
・踏み台サーバからCLIでOpenshiftにログインできるか
・プロジェクトの作成及び削除ができるか
・ユーザの作成及び削除ができるか

今回の記事では**ユーザの作成及び削除ができるか**にフォーカスしてまとめていきます

###### htpasswdファイルのSecret作成

以下コマンドでルートディレクトリ以下に、htpasswdファイルを作成します。

```
htpasswd -c -B -b ~/htpasswd admin hoge
Adding password for user admin
```
コマンドの意味の詳細は[こちらのリンク](https://qiita.com/masakuni-ito/items/3d951035884184632b99)を確認ください
今回は、ユーザで名が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:<ユーザ名>

```

以上です。

###### 参考

https://www.mtioutput.com/entry/openshift-make-user

https://note.com/shift_tech/n/n83208fa1c054

https://thinkit.co.jp/article/15937#:~:text=PVC%E3%81%AF%E3%80%81%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%82%92%E8%A6%81%E6%B1%82,%E8%A6%81%E6%B1%82%E3%81%8C%E7%99%BA%E7%94%9F%E3%81%97%E3%81%BE%E3%81%99%E3%80%82

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.3/html/authentication/configuring-identity-providers


## 環境
確認取れ次第記載します

## 終わりに
今回はOpenshiftのユーザー作成を通じて、認証と認可について深堀することができました。
普段何気なく使用しているオフィスの認証も、仕組みを理解すると面白いですね。

今後とも、”とりあえず使用しているが、仕組みを理解していないもの”の深堀を続けていければと思っております。