4.5. レポート Operator の設定


重要

メータリングは非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

OpenShift Container Platform で非推奨となったか、または削除された主な機能の最新の一覧については、OpenShift Container Platform リリースノートの 非推奨および削除された機能セクションを参照してください。

レポート Operator は、Prometheus からデータを収集し、メトリクスを Presto に保存して、Presto に対してレポートクエリーを実行し、それらの結果を HTTP API 経由で公開します。レポート Operator の設定は主に MeteringConfig カスタムリソースで実行されます。

4.5.1. Prometheus 接続のセキュリティー保護

メータリングを OpenShift Container Platform にインストールする場合、Prometheus は https://prometheus-k8s.openshift-monitoring.svc:9091/ で利用できます。

Prometheus への接続のセキュリティーを保護するために、デフォルトのメータリングのインストールでは OpenShift Container Platform の認証局 (CA) を使用します。Prometheus インスタンスが別の CA を使用する場合、CA は設定マップを使用して挿入できます。レポート Operator は、指定されたベアラートークンを使用して Prometheus で認証するように設定することもできます。

手順

  • 設定マップを使用して Prometheus インスタンスが使用する CA を挿入します。以下は例になります。

    spec:
      reporting-operator:
        spec:
          config:
            prometheus:
              certificateAuthority:
                useServiceAccountCA: false
                configMap:
                  enabled: true
                  create: true
                  name: reporting-operator-certificate-authority-config
                  filename: "internal-ca.crt"
                  value: |
                    -----BEGIN CERTIFICATE-----
                    (snip)
                    -----END CERTIFICATE-----

    または、一般に有効な証明書のシステム認証局を使用するには、 useServiceAccountCA および configMap.enabled の両方を false に設定します。

  • Prometheus で認証するベアラートークンを指定します。以下は例になります。
spec:
  reporting-operator:
    spec:
      config:
        prometheus:
          metricsImporter:
            auth:
              useServiceAccountToken: false
              tokenSecret:
                enabled: true
                create: true
                value: "abc-123"

4.5.2. レポート API の公開

OpenShift Container Platform では、デフォルトのメータリングインストールはルートを自動的に公開し、レポート API を利用可能にします。これにより、以下の機能が提供されます。

  • 自動 DNS
  • クラスター CA に基づく自動 TLS

また、デフォルトのインストールでは、OpenShift Container Platform サービスを使用して証明書を提供し、レポート API を TLS で保護することができます。OpenShift Container Platform OAuth プロキシーはレポート Operator のサイドカーコンテナーとしてデプロイされ、レポート API を認証で保護します。

4.5.2.1. OpenShift Container Platform 認証の使用

デフォルトで、レポート API のセキュリティーは TLS および認証で保護されます。これは、レポート Operator をレポート Operator のコンテナーおよび OpenShift Container Platform 認証プロキシーを実行するサイドカーコンテナーの両方を含む Pod をデプロイするように設定して実行されます。

レポート API にアクセスするために、メータリング Operator はルートを公開します。ルートがインストールされたら、以下のコマンドを実行してルートのホスト名を取得できます。

$ METERING_ROUTE_HOSTNAME=$(oc -n openshift-metering get routes metering -o json | jq -r '.status.ingress[].host')

次に、サービスアカウントトークンまたはユーザー名およびパスワードによる基本認証のいずれかを使用して認証を設定します。

4.5.2.1.1. サービスアカウントトークンを使用した認証

この方法では、以下のコマンドを使用してトークンをレポート Operator のサービスアカウントで使用し、そのベアラートークンを Authorization ヘッダーに渡します。

$ TOKEN=$(oc -n openshift-metering serviceaccounts get-token reporting-operator)
curl -H "Authorization: Bearer $TOKEN" -k "https://$METERING_ROUTE_HOSTNAME/api/v1/reports/get?name=[Report Name]&namespace=openshift-metering&format=[Format]"

上記の URL の name=[Report Name] および format=[Format] パラメーターを置き換えます。format パラメーターは、json、csv、または tabular にすることができます。

4.5.2.1.2. ユーザー名とパスワードを使用した認証

メータリングは、htpasswd ファイルの内容に指定されるユーザー名とパスワードの組み合わせを使用する基本認証の設定をサポートします。デフォルトで、空の htpasswd データを含むシークレットが作成されます。ただし、reporting-operator.spec.authProxy.htpasswd.data および reporting-operator.spec.authProxy.htpasswd.createSecret キーを、この方法を使用するように設定できます。

MeteringConfig で上記を指定した後に、以下のコマンドを実行できます。

$ curl -u testuser:password123 -k "https://$METERING_ROUTE_HOSTNAME/api/v1/reports/get?name=[Report Name]&namespace=openshift-metering&format=[Format]"

testuser:password123 を有効なユーザー名とパスワードの組み合わせに置き換えます。

4.5.2.2. 認証の手動設定

レポート Operator で OAuth を手動で設定するか、または無効にするには、MeteringConfig リソースで spec.tls.enabled: false を設定する必要があります。

警告

これは、レポート Operator、Presto、および Hive 間のすべての TLS および認証も無効にします。これらのリソースは手動で設定する必要があります。

認証を有効にするには、以下のオプションを設定します。認証を有効にすると、レポート Operator Pod が OpenShift Container Platform 認証プロキシーを Pod のサイドカーコンテナーとして実行するように設定されます。これによりポートが調整され、レポート API が直接公開されず、代わりに認証プロキシーサイドカーコンテナーでプロキシーされます。

  • reporting-operator.spec.authProxy.enabled
  • reporting-operator.spec.authProxy.cookie.createSecret
  • reporting-operator.spec.authProxy.cookie.seed

reporting-operator.spec.authProxy.enabled および reporting-operator.spec.authProxy.cookie.createSecrettrue に設定し、reporting-operator.spec.authProxy.cookie.seed を 32 文字のランダムな文字列に設定する必要があります。

以下のコマンドを使用して、32 文字のランダムな文字列を生成できます。

$ openssl rand -base64 32 | head -c32; echo.
4.5.2.2.1. トークン認証

以下のオプションが true に設定されている場合、ベアラートークンを使用する認証がレポート REST API に対して有効になります。ベアラートークンはサービスアカウントまたはユーザーから送られる場合があります。

  • reporting-operator.spec.authProxy.subjectAccessReview.enabled
  • reporting-operator.spec.authProxy.delegateURLs.enabled

認証が有効にされると、ユーザーまたはサービスアカウントのレポート API をクエリーするために使用されるベアラートークンに、以下のロールのいずれかを使用するアクセスが付与される必要があります。

  • report-exporter
  • reporting-admin
  • reporting-viewer
  • metering-admin
  • metering-viewer

メータリング Operator は、spec.permissions セクションにサブジェクトの一覧を指定して、ロールバインディングを作成し、これらのパーミッションを付与できます。たとえば、以下の advanced-auth.yaml の設定例を参照してください。

apiVersion: metering.openshift.io/v1
kind: MeteringConfig
metadata:
  name: "operator-metering"
spec:
  permissions:
    # anyone in the "metering-admins" group can create, update, delete, etc any
    # metering.openshift.io resources in the namespace.
    # This also grants permissions to get query report results from the reporting REST API.
    meteringAdmins:
    - kind: Group
      name: metering-admins
    # Same as above except read only access and for the metering-viewers group.
    meteringViewers:
    - kind: Group
      name: metering-viewers
    # the default serviceaccount in the namespace "my-custom-ns" can:
    # create, update, delete, etc reports.
    # This also gives permissions query the results from the reporting REST API.
    reportingAdmins:
    - kind: ServiceAccount
      name: default
      namespace: my-custom-ns
    # anyone in the group reporting-readers can get, list, watch reports, and
    # query report results from the reporting REST API.
    reportingViewers:
    - kind: Group
      name: reporting-readers
    # anyone in the group cluster-admins can query report results
    # from the reporting REST API. So can the user bob-from-accounting.
    reportExporters:
    - kind: Group
      name: cluster-admins
    - kind: User
      name: bob-from-accounting

  reporting-operator:
    spec:
      authProxy:
        # htpasswd.data can contain htpasswd file contents for allowing auth
        # using a static list of usernames and their password hashes.
        #
        # username is 'testuser' password is 'password123'
        # generated htpasswdData using: `htpasswd -nb -s testuser password123`
        # htpasswd:
        #   data: |
        #     testuser:{SHA}y/2sYAj5yrQIN4TL0YdPdmGNKpc=
        #
        # change REPLACEME to the output of your htpasswd command
        htpasswd:
          data: |
            REPLACEME

または、get パーミッションを reports/export に付与するルールを持つすべてのロールを使用できます。これは、レポート Operator の namespace の Report リソースの export サブリソースに対する get アクセスです。例: admin および cluster-admin

デフォルトで、レポート Operator およびメータリング Operator サービスアカウントにはどちらにもこれらのパーミッションがあり、それらのトークンを認証に使用することができます。

4.5.2.2.2. ユーザー名とパスワードを使用した基本認証

基本認証では、reporting-operator.spec.authproxy.htpasswd.data フィールドにユーザー名とパスワードを指定することができます。ユーザー名とパスワードは htpasswd ファイルにあるものと同じ形式である必要があります。設定されている場合、htpasswdData のコンテンツに対応するエントリーのあるユーザー名とパスワードを指定するために HTTP 基本認証を使用できます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.