ArgoCDのGithubとのSSO連携設定

# 概要
ArgoCDを複数チームで使用しようとした場合、各開発チームに管理ユーザを渡すのではなく、個別のローカルユーザーを渡したい。デフォルトでは管理ユーザしか存在しないので、ローカルユーザーを作成する方法について調査して、試してみた。

結論から書くと、
ArgoCDは組込みのadminユーザ以外に自前でローカルユーザーを作成する手段を持ち合わせていない。
**admin以外のユーザはSSOを介してログイン**させる必要がある。
SSOを設定する方法は2つ用意されていて

1. インストール時に同梱されている[Dex](https://qiita.com/superbrothers/items/1822dbc5fc94e1ab5295#coreosdex)を認証プロバイダとして使用し、Dexのコネクタ機能を利用して外部の認証プロバイダと連携する方法
2. Dexを使わずに認証プロバイダを直接設定する方法

今回は1.の方法を使ってGithubアカウントでログインできるようにしてみます。


# SSO連携設定
今回は連携先をGithubとして、以下のページを参考にしながら進めていきます。  
[SSO Configuration](https://argoproj.github.io/argo-cd/operator-manual/sso/)

## ArgoCDをセットアップ
まずは、以前[私が書いた記事](https://qiita.com/ttr_tkmkb/items/ff4d88f3a91db982b0ab)を参考にログインが確認できる部分までセットアップ。
GCPアカウントが既に有ればクラスタ起動までの待機時間込みで、脳死コピペで10分ぐらいでセットアップできます。

## Github(設定するIDプロバイダ)にArgoCDを登録

Githubにログインして、以下のURLにアクセス。
https://github.com/settings/developers

OAuth Apps -> Register a new applicationと進む。

![Cut2019_0707_1003_34.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411298/b8981590-ca2e-cbcb-1ce5-4a370214f8b2.jpeg)

必要な情報を入力して、Regiter applicationをクリック。  
callback URLの形式は`/api/dex/callback`であること。

![Cut2019_0707_1006_58.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411298/42ff0dba-857c-17e9-3f11-c571b7952c3f.jpeg)

登録が完了すると、OAuth2クライアントIDとシークレットが発行される。（既に削除済みなのでSecretも公開していく）

![Cut2019_0707_1009_39.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411298/ea86e2cd-b0fd-a074-944f-333521c696e9.jpeg)


## ArgoCDにSSO連携設定
SSOの連携先を設定するために、argocdのconfigmapを編集する。
本当はArgoCD自体もGitOpsでやりたい。。その方法はまた今度。

```
kubectl edit configmap argocd-cm -n argocd
```

以下の設定を追加しました。
clientSecretは別途暗号化したほうが良いです。今回はそのまま書きました。

```
data:
  #ArgoCDのURL
  url: https://35.221.69.97
  dex.config: |
    connectors:
      - type: github
        id: github
        name: GitHub
        #先ほど取得したIDとシークレットを記入
        config:
          clientID: 183d1478019b1b089c78
          clientSecret: 523641358a11ac37434bd92dd234e465b72bb305

```
あとは自動で反映されます。

## ArgoCDにGithubアカウントでログイン
ArgoCDにアクセスします。
これまで無かった`LOGIN VIA GITHUB`なる文字が追加されました。クリックしてみます。

![Cut2019_0707_1020_35.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411298/b3c53251-971e-7ef9-5125-1481483b7da8.jpeg)

Githubアカウントで認証するかの確認を求められます。進めます。
![Cut2019_0707_1021_19.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411298/ef4bb00a-d7f3-3ff2-a3c4-2f4925e9f75c.jpeg)

Githubアカウントでログインできました！
![Cut2019_0707_1034_03.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/411298/901728d1-f861-6aa8-c245-77fccf6e8aa4.jpeg)

## オマケ：ログインログの確認
監査対応のためにログインのログも確認する必要がありますよね。
podの標準出力を確認して、ログを吐いているか確認します。

```
$ kubectl get pod -n argocd
NAME                                            READY   STATUS    RESTARTS   AGE
argocd-application-controller-9c45ddc4c-v82th   1/1     Running   2          71m
argocd-dex-server-7b9ccb486-w2ljp               1/1     Running   0          71m
argocd-redis-ha-server-0                        2/2     Running   0          71m
argocd-redis-ha-server-1                        2/2     Running   0          70m
argocd-redis-ha-server-2                        2/2     Running   0          70m
argocd-repo-server-5994b64ccb-2drhx             1/1     Running   0          71m
argocd-repo-server-5994b64ccb-v7vgw             1/1     Running   0          71m
argocd-server-569c655c64-cxwx4                  1/1     Running   0          71m
argocd-server-569c655c64-dqvp5                  1/1     Running   0          71m

```

まずは、OIDCプロバイダとの連携を担当している、dexサーバのログを確認してみます。

```
$ kubectl logs argocd-dex-server-7b9ccb486-w2ljp -n argocd
###一部省略
time="2019-07-07T01:31:25Z" level=info msg="login successful: connector \"github\", username=\"ssbtn\", email=\"aaaaa\", groups=[]"

```

githubアカウントでログインした際のログは確認できていますね。
ただ、adminアカウントでログインした際のログはありませんでした。
次に有用なログが有りそうなargocd-serverのログを確認してみます。

```
$ kubectl logs argocd-server-569c655c64-dqvp5 -n argocd
###一部省略
time="2019-07-07T01:44:40Z" level=info msg="received streaming call /application.ApplicationService/Watch" grpc.method=Watch grpc.request.claims="{\"iat\":1562463880,\"iss\":\"argocd\",\"nbf\":1562463880,\"sub\":\"admin\"}" grpc.request.content="resourceVersion:\"\" " grpc.service=application.ApplicationService grpc.start_time="2019-07-07T01:44:40Z" span.kind=server system=grpc


time="2019-07-07T01:46:23Z" level=info msg="received streaming call /application.ApplicationService/Watch" grpc.method=Watch grpc.request.claims="{\"at_hash\":\"qL7WGdPxHJ5K3vkBwGz44w\",\"aud\":\"argo-cd\",\"email\":\"aaaaaaa\",\"email_verified\":true,\"exp\":1562550382,\"iat\":1562463982,\"iss\":\"https://35.221.69.97/api/dex\",\"name\":\"ssbtn\",\"sub\":\"Cgg0NzkzNTU3NRIGZ2l0aHVi\"}" grpc.request.content="resourceVersion:\"\" " grpc.service=application.ApplicationService grpc.start_time="2019-07-07T01:46:23Z" span.kind=server system=grpc
```

adminのログインも含めて、ArgoCDの操作に関する諸々のログがargocd-serverに吐かれていました。
ただ、今回は冗長構成にしているので、どちらに吐かれるか分からず見づらかったです。。やっぱり、コンテナのログは生で見るものじゃないですね。

# 所感
SSOの連携先はOIDCプロバイダーやLDAPであれば何でも良いので、エンタープライズで利用する場合はプライベートクラウドやオンプレに立てたGitOpsをするためのGitlabサーバが有力な連携先になるのかなと思いました。

GitOpsをするに当たり、前提としてGithubやGitlabのアカウントが存在することになります。
ローカルユーザーの管理は作成機能を持たせずに、SSO連携のみに絞っていて、不用意にユーザ管理が多重化するのを防いでおり、クールだなと思いました。

# 参考
[SSO Configuration](https://argoproj.github.io/argo-cd/operator-manual/sso/)