前書き

Kubernetes ingressesを使用すると、Webサービスをインターネットに簡単に公開できます。 ただし、プライベートサービスに関しては、アクセスできるユーザーを制限する必要があります。 oauth2_proxyは、パブリックインターネットサービスとプライベートサービスの間の障壁として機能します。 oauth2_proxyは、GitHubなどのさまざまなプロバイダーを使用して認証を提供するリバースプロキシおよびサーバーであり、電子メールアドレスまたはその他のプロパティによってユーザーを検証します。

このチュートリアルでは、GitHubでoauth2_proxyを使用してサービスを保護します。 完了すると、次の図のような承認システムが作成されます。

image:https://assets.digitalocean.com/articles/doks_private_oauth/W0VBgjC.png [リクエストフローの最終結果の図]

前提条件

このチュートリアルを完了するには、次のものが必要です。

  • NginxイングレスとLet’s Encryptで実行される2つのWebサービスを持つKubernetesクラスター。 このチュートリアルは、https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes [Nginxをセットアップする方法DigitalOcean KubernetesのCert-Managerとのイングレス]。 このチュートリアルを完了するには、最後まで必ず従ってください。

  • https://github.com [GitHub]アカウント。

  • ローカルマシンにインストールされたPython。 インストールしていない場合は、https://www.digitalocean.com/community/tags/python?type = tutorials#install-and-configure-python [オペレーティングシステムのインストール手順]に従ってください。

手順1-ドメインの構成

「前提条件」セクションにリンクされているチュートリアルを実行すると、クラスターで実行されている2つのWebサービス、「+ echo1 」と「 echo2 」があります。 また、 ` echo1。`と ` echo2。+`を対応するサービスにマッピングするイングレスが1つあります。

このチュートリアルでは、次の規則を使用します。

  • すべてのプライベートサービスは、 `+ service.int。`のように、 ` .int。`サブドメインに分類されます。 認証Cookieはすべての「 *。int。+」サブドメインで共有されるため、1つのサブドメインの下にプライベートサービスをグループ化することが理想的です。

  • ログインポータルは `+ auth.int。+`で提供されます。

開始するには、既存のイングレス定義を更新して、「。int。」の下で「+ echo1 」および「 echo2 」サービスを移動します。 ドメインを変更できるように、テキストエディターで ` echo_ingress.yaml +`を開きます。

nano echo_ingress.yaml

`+ echo1。`のすべてのインスタンスの名前を ` echo1.int。`に変更し、 ` echo2。`のすべてのインスタンスを ` echo2。+`に置き換えます。

echo_ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: echo-ingress
 annotations:
   kubernetes.io/ingress.class: nginx
   certmanager.k8s.io/cluster-issuer: letsencrypt-prod
spec:
 tls:
 - hosts:
   - echo1.
   - echo2.
   secretName: letsencrypt-prod
 rules:
 - host: echo1.
   http:
     paths:
     - backend:
         serviceName: echo1
         servicePort: 80
 - host: echo2.
   http:
     paths:
     - backend:
         serviceName: echo2
         servicePort: 80

ファイルを保存し、変更を適用します。

kubectl apply -f echo_ingress.yaml

これにより、 `+ echo1 `および ` echo2 +`サービスのTLS証明書も更新されます。

DNS構成を更新して、行った変更を反映します。 まず、次のコマンドを実行してNginxイングレスのIPアドレスを検索し、詳細を出力します。

kubectl get svc --namespace=ingress-nginx

出力の `+ EXTERNAL-IP +`の下にIPアドレスが表示されます。

OutputNAME            TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                      AGE
ingress-nginx   LoadBalancer         80:32486/TCP,443:32096/TCP   20h

外部IPアドレスをクリップボードにコピーします。 DNS管理サービスを参照し、 `+ echo1-2。+`の* A *レコードを見つけて、その外部IPアドレスを指すようにします。 DigitalOceanを使用してDNSレコードを管理している場合は、https://www.digitalocean.com/docs/networking/dns/how-to/manage-records/ [DNSレコードの管理方法]で手順を参照してください。

`+ echo1 `および ` echo2 `のレコードを削除します。 ホスト名「 *。int。」の新しい「 A +」レコードを追加し、イングレスの外部IPアドレスをポイントします。

これで、 `+ *。int。+`の下にあるサブドメインへのリクエストはすべてNginxイングレスにルーティングされるため、クラスター内でこれらのサブドメインを使用できます。

次に、GitHubをログインプロバイダーとして構成します。

ステップ2-GitHub OAuthアプリケーションの作成

oauth2_proxyは、さまざまなログインプロバイダーをサポートします。 このチュートリアルでは、GitHubプロバイダーを使用します。 開始するには、新しいGitHub OAuthアプリを作成します。

アカウントのhttps://github.com/settings/developers [開発者設定の[OAuthアプリ]タブ]ページで、[新しいOAuthアプリ]ボタンをクリックします。

*アプリケーション名*および*ホームページURL *フィールドには、任意の名前を指定できます。 * Authorization callback URL *フィールドに、「+ https:// auth.int。/ oauth2 / callback + `」と入力します。

アプリケーションを登録した後、クライアントIDとシークレットを受け取ります。 次のステップで必要になるため、この2つに注意してください。

GitHub OAuthアプリケーションを作成したので、oauth2_proxyをインストールして構成できます。

ステップ3 –ログインポータルの設定

Helmを使用してoauth2proxyをクラスターにインストールします。 最初に、GitHubアプリケーションのクライアントIDとシークレットを保持するKubernetesシークレットと、oauth2proxyによって設定されたブラウザーCookieの暗号化シークレットを作成します。

次のコマンドを実行して、安全なCookieシークレットを生成します。

python -c 'import os,base64; print base64.b64encode(os.urandom(16))'

結果をクリップボードにコピーします

次に、Cookieシークレット、GitHubクライアントID、およびGitHubシークレットキーの強調表示された値を置き換えて、Kubernetesシークレットを作成します。

kubectl -n default create secret generic oauth2-proxy-creds \
--from-literal=cookie-secret= \
--from-literal=client-id= \
--from-literal=client-secret=

次の出力が表示されます。

Outputsecret/oauth2-proxy-creds created

次に、 `+ oauth2-proxy-config.yaml `という名前の新しいファイルを作成します。このファイルには、 ` oauth2_proxy +`の設定が含まれます。

nano oauth2-proxy-config.yaml

このファイルで設定する値は、ヘルムチャートのデフォルトを上書きします。 ファイルに次のコードを追加します。

oauth2-proxy-config.yaml

config:
 existingSecret: oauth2-proxy-creds

extraArgs:
 whitelist-domain: .int.
 cookie-domain: .int.
 provider: github

authenticatedEmailsFile:
 enabled: true
 restricted_access: |-



ingress:
 enabled: true
 path: /
 hosts:
   - auth.int.
 annotations:
   kubernetes.io/ingress.class: nginx
   certmanager.k8s.io/cluster-issuer: letsencrypt-prod
 tls:
   - secretName: oauth2-proxy-https-cert
     hosts:
       - auth.int.

このコードは次のことを行います。

  1. 作成したシークレットを使用するようにoauth2_proxyに指示します。

  2. ドメイン名とプロバイダータイプを設定します。

  3. 許可されたメールアドレスのリストを設定します。 GitHubアカウントがこれらのメールアドレスのいずれかに関連付けられている場合、プライベートサービスへのアクセスが許可されます。

  4. Let’s EncryptのTLS証明書を使用して、 `+ auth.int。+`のログインポータルにサービスを提供するイングレスを設定します。

シークレットと設定ファイルの準備ができたので、 `+ oauth2_proxy +`をインストールできます。 次のコマンドを実行してください。

helm repo update \
&& helm upgrade oauth2-proxy --install stable/oauth2-proxy \
--reuse-values \
--values oauth2-proxy-config.yaml

Let’s Encrypt証明書の発行とインストールには数分かかる場合があります。

展開が成功したことをテストするには、 `+ https:// auth.int。+`を参照します。 GitHubでログインするように求めるページが表示されます。

oauth2_proxyをセットアップして実行すると、サービスで認証を要求するだけです。

ステップ4-プライベートサービスの保護

サービスを保護するために、oauth2_proxyを介して認証を実施するようにNginx入力を設定します。 Nginxとnginx-ingressはこの構成をネイティブでサポートしているため、イングレス定義にいくつかの注釈を追加するだけで済みます。

前提条件のチュートリアルで設定した「+ echo1 」および「 echo2 」サービスを保護しましょう。 エディターで ` echo_ingress.yaml +`を開きます:

nano echo_ingress.yaml

認証を要求するために、これら2つの追加の注釈をファイルに追加します。

echo_ingress.yaml

  annotations:
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod

ファイルを保存し、変更を適用します。

kubectl apply -f echo_ingress.yaml

これで、 `+ https:// echo1.int。`を参照すると、アクセスするためにGitHubを使用してログインするように求められます。 有効なアカウントでログインすると、 ` echo1 `サービスにリダイレクトされます。 同じことが ` echo2 +`にも当てはまります。

結論

このチュートリアルでは、Kubernetesクラスターでoauth2_proxyを設定し、GitHubログインの背後にあるプライベートサービスを保護しました。 保護する必要のある他のサービスについては、ステップ4で説明されている手順に従ってください。

oauth2_proxyは、GitHub以外のさまざまなプロバイダーをサポートしています。 さまざまなプロバイダーの詳細については、https://pusher.github.io/oauth2_proxy/auth-configuration [公式ドキュメント]を参照してください。

さらに、多くの構成パラメーターを調整する必要がありますが、デフォルトはほとんどのニーズに適合します。 パラメータのリストについては、https://github.com/helm/charts/tree/master/stable/oauth2-proxy [ヘルムチャートのドキュメント]およびhttps://pusher.github.io/oauth2_proxy/configuration[oauth2_proxy’sドキュメンテーション]。