本書では、OpenShift Container Platform で有効なコンテナーのセキュリティー対策についての概要を説明します。これには、ホスト層、コンテナーとオーケストレーション層、およびビルドとアプリケーション層の各種ソリューションが含まれます。本書には、以下の情報が記載されています。

コンテナーは、アプリケーションとそのすべての依存関係を 1 つのイメージにパッケージ化します。このイメージは、変更なしに開発環境からテスト環境、実稼働環境へとプロモートすることができます。

コンテナーは、複数の環境、および物理サーバー、仮想マシン (VM)、およびプライベートまたはパブリッククラウドなどの複数のデプロイメントターゲット間に一貫性をもたらします。

コンテナーを使用するメリットには以下が含まれます。

参考文献

本書では、コンテナーソリューションスタックの各層でのセキュリティーの重要な要素について説明します。 さらに、各段階および各層でのセキュリティーに留意しつつ OpenShift Container Platform を使用したコンテナーの作成、デプロイ、およびスケーリング時の管理の方法についても説明します。

参考文献

コンテナーは、複数のアプリケーションを単一ホストにデプロイすることで、マルチテナンシーのデプロイメントを単純化します。 この際、カーネルおよび Docker ランタイムを使用して各コンテナーをスピンアップします。

ホストカーネルのセキュリティーを保護し、コンテナーを相互にセキュアにすることのできるオペレーティングシステム (OS) を使用する必要があります。Linux では、コンテナーは特殊なタイプのプロセスに過ぎないため、コンテナーのセキュリティーを保護することは、実行中のプロセスのセキュリティーを保護することと同じです。コンテナーは非 root ユーザーとして実行される必要があります。権限レベルを下げることや、可能な限り権限レベルを低くした状態でコンテナーを作成することが推奨されます。

OpenShift Container Platform は Red Hat Enterprise Linux (RHEL) および RHEL Atomic Host で実行されるため、デフォルトで以下の概念がデプロイされる OpenShift Container Platform クラスターに適用されます。 また、これらはプラットフォーム上でコンテナーのセキュリティーを保護する上で中核を成す概念になります。

参考文献

従来の仮想化もマルチテナンシーを可能にしますが、コンテナーの場合とは全く異なる方法でこれを実行します。仮想化は、ゲスト仮想マシン (VM) をスピンアップするハイパーバイザーを使用します。 仮想マシンはそれぞれ、独自のオペレーティングシステム (OS) のほか、実行するアプリケーションとその依存関係を備えています。

仮想マシンの場合、ハイパーバイザーはゲスト同士を分離させ、ゲストをホストカーネルから分離します。ハイパーバイザーにアクセスする個々のユーザーおよびプロセスの数は少ないため、物理サーバーで攻撃される対象の規模が縮小します。とはいえ、この場合もセキュリティーの監視が依然として必要になります。あるゲスト仮想マシンがハイパーバイザーのバグを利用して、別の仮想マシンまたはホストカーネルにアクセスできる可能性があります。 また、OS にパッチを当てる必要がある場合は、その OS を使用するすべてのゲスト仮想マシンにパッチを当てる必要があります。

コンテナーはゲスト仮想マシン内で実行可能であり、これが必要になる場合のユースケースもあるでしょう。たとえば、リフトアンドシフト方式でアプリケーションをクラウドに移行するなど、コンテナーに従来型のアプリケーションをデプロイする場合などです。しかし、単一ホストでのコンテナーマルチテナンシーはより軽量で、柔軟性があり、スケーリングしやすいデプロイメントソリューションを提供します。このデプロイメントモデルは、クラウドネイティブなアプリケーションにとくに適しています。

参考文献

アプリケーションとインフラストラクチャーは、すぐに利用できるコンポーネントで設定されています。その多くは、Linux オペレーティングシステム、JBoss Web Server、PostgreSQL、および Node.js などのオープンソースパッケージです。

これらのパッケージのコンテナー化されたバージョンも利用できます。ただし、パッケージの出所や、ビルドした人、パッケージの中に悪質なコードが含まれているかどうかを確認する必要があります。

確認するべき点には以下が含まれます。

参考文献

コンテナースキャンツールは、継続的に更新される脆弱性のデータベースを利用して、コンテナーのコンテンツの既知の脆弱性についての最新情報を常に利用可能にします。既知の脆弱性についての一覧は絶えず変更されるため、コンテナーイメージの初回ダウンロード時にそれらのコンテンツについて確認し、承認済みおよびデプロイ済みのすべてのイメージの脆弱性について継続的に追跡する必要があります。

RHEL はプラグ可能な API を提供し、複数のスキャナーをサポートします。Red Hat CloudForms を OpenSCAP と共に使用して、コンテナーイメージをスキャンしてセキュリティー問題の有無を確認することもできます。RHEL での OpenSCAP についての一般的な情報は、コンプライアンスおよび OpenSCAP を使った脆弱性のスキャン を参照してください。 また、OpenSCAP 統合の詳細については、Red Hat CloudForms Policies and Profiles Guide を参照してください。

OpenShift Container Platform では、このようなスキャナーを CI/CD プロセスで利用することができます。たとえば、ソースコードのセキュリティー上の欠陥をテストする静的コード解析ツールや、既知の脆弱性などのメタデータを提供する必要のあるオープンソースライブラリーを特定するソフトウェアコンポジション解析ツールを統合することができます。詳細は、ビルドプロセス で説明されています。

OpenShift Container Platform は、オブジェクトのアノテーション (object annotations) を利用して機能を拡張します。脆弱性スキャナーなどの外部ツールはイメージオブジェクトにメタデータのアノテーションを付けることで、結果の要約を表示したり、Pod の実行を制御したりできます。本セクションでは、このアノテーションの認識される形式について説明します。 この形式を使用することで、アノテーションをコンソールで安全に使用し、ユーザーに役立つデータを表示することができます。

quality.images.openshift.io/<qualityType>.<providerId>: {}

quality.images.openshift.io/vulnerability.blackduck: {}
quality.images.openshift.io/vulnerability.jfrog: {}
quality.images.openshift.io/license.blackduck: {}
quality.images.openshift.io/vulnerability.openscap: {}

{
  "name": "OpenSCAP",
  "description": "OpenSCAP vulnerability score",
  "timestamp": "2016-09-08T05:04:46Z",
  "reference": "https://www.open-scap.org/930492",
  "compliant": true,
  "scannerVersion": "1.2",
  "summary": [
    { "label": "critical", "data": "4", "severityIndex": 3, "reference": null },
    { "label": "important", "data": "12", "severityIndex": 2, "reference": null },
    { "label": "moderate", "data": "8", "severityIndex": 1, "reference": null },
    { "label": "low", "data": "26", "severityIndex": 0, "reference": null }
  ]
}

{
  "name": "Red Hat Container Catalog",
  "description": "Container health index",
  "timestamp": "2016-09-08T05:04:46Z",
  "reference": "https://access.redhat.com/errata/RHBA-2016:1566",
  "compliant": null,
  "scannerVersion": "1.2",
  "summary": [
    { "label": "Health index", "data": "B", "severityIndex": 1, "reference": null }
  ]
}

$ oc annotate image <image> \
    quality.images.openshift.io/vulnerability.redhatcatalog='{ \
    "name": "Red Hat Container Catalog", \
    "description": "Container health index", \
    "timestamp": "2016-09-08T05:04:46Z", \
    "compliant": null, \
    "scannerVersion": "1.2", \
    "reference": "https://access.redhat.com/errata/RHBA-2016:1566", \
    "summary": "[ \
      { "label": "Health index", "data": "B", "severityIndex": 1, "reference": null } ]" }'

annotations:
  images.openshift.io/deny-execution: true

$ curl -X PATCH \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/merge-patch+json" \
  https://<openshift_server>:8443/oapi/v1/images/<image_id> \
  --data '{ <image_annotation> }'

{
"metadata": {
  "annotations": {
    "quality.images.openshift.io/vulnerability.redhatcatalog":
       "{ 'name': 'Red Hat Container Catalog', 'description': 'Container health index', 'timestamp': '2016-09-08T05:04:46Z', 'compliant': null, 'reference': 'https://access.redhat.com/errata/RHBA-2016:1566', 'summary': [{'label': 'Health index', 'data': '4', 'severityIndex': 1, 'reference': null}] }"
    }
  }
}

ダウンロード済みかつデプロイ済みのコンテナーイメージのコンテンツをスキャンし、追跡するには各種のツールを使用できます。しかし、コンテナーイメージの公開ソースは数多くあります。公開されているコンテナーレジストリーを使用する場合は、信頼されるソースを使用して保護用の層を追加することができます。

イミュータブルなコンテナー を管理する際に、セキュリティー更新を使用することはとくに重要になります。イミュータブルなコンテナーは、実行中には変更されることのないコンテナーです。イミュータブルなコンテナーをデプロイする場合には、実行中のコンテナーにステップインして 1 つ以上のバイナリーを置き換えることはできません。 更新されたコンテナーイメージを再度ビルドし、デプロイする必要があります。

以下は、Red Hat 認定イメージの特徴になります。

既知の脆弱性の一覧は常に更新されるので、デプロイ済みのコンテナーイメージのコンテンツのほか、新規にダウンロードしたイメージを継続的に追跡する必要があります。Red Hat セキュリティーアドバイザリー (RHSA) を利用して、Red Hat 認定コンテナーイメージで新たに発見される問題についての警告を受け、更新されたイメージを確認することができます。

参考文献

Red Hat は、Red Hat レジストリー を使用して Red Hat 製品およびパートナー企業のオファリングの認定コンテナーを提供します。これは、registry.redhat.io で Red Hat がホストする公開コンテナーレジストリーです。Red Hat Container Catalog を使用すると、Red Hat レジストリーで提供されるコンテナーイメージと関連したバグ修正またはセキュリティーアドバイザリーを確認できます。

Red Hat ではコンテナーのコンテンツの脆弱性を監視し、コンテンツを定期的に更新しています。glibc、Drown、または Dirty Cow の修正など、Red Hat がセキュリティー更新をリリースする際に、影響を受けるすべてのコンテナーイメージも再ビルドされ、Red Hat Registry にプッシュされます。

Red Hat は、Red Hat Container Catalog で提供されるコンテナーのセキュリティーリスクについて健全性のインデックスを使用します。Red Hat は、エラータプロセスでソフトウェアを提供します。 セキュリティーのレベルは、コンテナーが古いと低くなり、新規のコンテナーの場合はセキュリティーのレベルが上がります。

コンテナーの年数について、Red Hat Container Catalog では格付けシステムを使用します。最新度についての評価は、イメージに利用できる最も古く、最も重大度の高いセキュリティーエラータに基づいて行われます。格付けは A から F まであり、A が最新となります。この格付けシステムの詳細については、Container Health Index grades as used inside the Red Hat Container Catalog を参照してください。

参考文献

OpenShift Container Platform には、OpenShift Container レジストリー が含まれます。OpenShift Container レジストリーは、ロールベースのアクセス制御を提供します。 これにより、どのコンテナーイメージを誰がプル/プッシュするのかを管理できるようになります。

また、OpenShift Container Platform はすでに使用中の他のプライベートレジストリーとの統合もサポートしています。

参考文献

コンテナー環境では、ソフトウェアのビルドプロセスはライフサイクルのステージであり、ここでは、アプリケーションコードが必要なランタイムライブラリーと統合されます。このビルドプロセスの管理は、ソフトウェアのスタックのセキュリティーを保護する上で鍵となります。

OpenShift Container Platform をコンテナービルドの標準プラットフォームとして使用することで、ビルド環境のセキュリティーを確保できます。1 回のビルドでどこにでもデプロイが可能という理念を背景に、ビルドプロセスの製品がそのままの状態で実稼働にデプロイされるようにすることができます。

コンテナーのイミュータブルな状態を維持することも重要です。実行中のコンテナーにパッチを当てることはできません。 その代わりに再ビルドおよび再デプロイを実行します。

Source-to-Image (S2I) を使用して、ソースコードとベースイメージを組み合わせることができます。ビルダーイメージ は S2I を利用し、開発および運用チームの再現可能なビルド環境での協業を可能にします。

開発者がビルドイメージを使用して、アプリケーション用に Git でコードをコミットする場合、OpenShift Container Platform は以下の機能を実行できます。

OpenShift Container レジストリーを使用して、最終イメージへのアクセスを管理できます。S2I イメージおよびネイティブビルドイメージの両方は OpenShift Container レジストリーに自動的にプッシュされます。

CI の組み込まれた Jenkins のほかに、独自のビルド/ CI 環境を RESTful API および API 準拠のイメージレジストリーを使用して OpenShift Container Platform に統合することもできます。

参考文献

シナリオによっては、ビルド操作において、依存するリソースにアクセスするために認証情報が必要になる場合がありますが、この認証情報をビルドで生成される最終的なアプリケーションイメージで利用可能にすることは適切ではありません。このため、入力シークレットを定義することができます。

たとえば、Node.js アプリケーションのビルド時に、Node.js モジュールのプライベートミラーを設定できます。プライベートミラーからモジュールをダウンロードするには、URL、ユーザー名、パスワードを含む、ビルド用のカスタム .npmrc ファイルを指定する必要があります。セキュリティー上の理由により、認証情報はアプリケーションイメージで公開しないでください。

この例で示したシナリオを使用して、入力シークレットを新規の BuildConfig に追加できます。

参考文献

コンテナーの層を使用できるようにコンテナーイメージ管理およびビルドプロセスを設計して、制御を分離可能にすることができます。

たとえば、運用チームはベースイメージを管理します。一方で、アーキテクトはミドルウェア、ランタイム、データベース、その他のソリューションを管理します。一方で、アーキテクトはミドルウェア、ランタイム、データベース、その他のソリューションを管理します。 これにより、開発者はアプリケーション層のみを使用し、コードの作成に集中することができます。

新しい脆弱性情報は常に更新されるので、コンテナーのコンテンツを継続的かつプロアクティブに確認する必要があります。これを実行するには、自動化されたセキュリティーテストをビルドまたは CI プロセスに統合する必要があります。以下に例を示します。

CI プロセスには、セキュリティースキャンで発見される問題について担当チームが適切に対処できるように、これらの問題のフラグをビルドに付けるポリシーを含める必要があります。カスタマイズしたコンテナーに署名することで、ビルドとデプロイメント間に改ざんが発生しないようにします。

参考文献

ビルドプロセスで何らかの問題が生じる場合や、イメージのデプロイ後に脆弱性が発見される場合に、自動化されるポリシーベースのデプロイを実行するツールを使用できます。イメージの再ビルドおよび置き換えはトリガーを使用して実行できます。 実行中のコンテナーにパッチを当てる方法は推奨されていません。

たとえば、3 つのコンテナーイメージ層 (コア、ミドルウェア、アプリケーション) を使用してアプリケーションをビルドするとします。コアイメージに問題が見つかり、そのイメージは再ビルドされました。ビルドが完了すると、イメージは OpenShift Container レジストリーにプッシュされます。OpenShift Container Platform はイメージが変更されたことを検知し、定義されたトリガーに基づいてアプリケーションイメージを自動的に再ビルドし、デプロイします。この変更には修正されたライブラリーが組み込まれ、実稼働コードが最新のイメージと同じ状態になります。

oc set triggers コマンドは、デプロイメント設定のデプロイメントトリガーを設定するために使用できます。たとえば、frontend というデプロイメント設定に ImageChangeTrigger を設定する場合は、以下を実行します。

$ oc set triggers dc/frontend \
    --from-image=myproject/origin-ruby-sample:latest \
    -c helloworld

参考文献

重要な点として、対象とするイメージが実際にデプロイされていることや、そのイメージが信頼されるソースからのものであること、またそれらが変更されていないことを確認できる必要があります。これは、暗号による署名を使用して実行できます。OpenShift Container Platform では、クラスター管理者がデプロイメント環境とセキュリティー要件を反映した (広義または狭義のものを含む) セキュリティーポリシーを適用できます。このポリシーは、以下の 2 つのパラメーターで定義されます。

これらのポリシーパラメーターにより、レジストリーまたはレジストリーの一部および個別のイメージもホワイトリスト化 (accept) またはブラックリスト化 (reject) するか、または信頼されたパブリックキーを使用して信頼関係を定義し、ソースが暗号を使って検証されていることを確認できます。このポリシールールはノードに適用されます。ポリシーは、すべてのノード全体に均一に適用されるか、または異なるノードのワークロード (例: ビルド、ゾーン、または環境) ごとにターゲットが設定される場合があります。

{
    "default": [{"type": "reject"}],
    "transports": {
        "docker": {
            "access.redhat.com": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ]
        },
        "atomic": {
            "172.30.1.1:5000/openshift": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ],
            "172.30.1.1:5000/production": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/example.com/pubkey"
                }
            ],
            "172.30.1.1:5000": [{"type": "insecureAcceptAnything"}]
        }
    }
}

ポリシーは /etc/containers/policy.json としてノードに保存できます。この例では、以下のルールを実施しています。

ホストの設定に関する詳細な説明については、イメージ署名サポートの有効化 を参照してください。署名トランスポート に関する詳細は、以下のセクションを参照してください。イメージ署名ポリシーに関する詳細は、署名検証ポリシーファイル形式 のソースコードについてのドキュメントを参照してください。

docker:
    access.redhat.com:
        sigstore: https://access.redhat.com/webassets/docker/content/sigstore

Secret オブジェクトタイプはパスワード、OpenShift Container Platform クライアント設定ファイル、dockercfg ファイル、プライベートソースリポジトリーの認証情報などの機密情報を保持するメカニズムを提供します。シークレットは機密内容を Pod から切り離します。シークレットはボリュームプラグインを使用してコンテナーにマウントすることも、システムが Pod の代わりにシークレットを使用して各種アクションを実行することもできます。

たとえば、プライベートイメージリポジトリーにアクセスできるように、シークレットを Web コンソールを使用してデプロイメント設定に追加するには、以下を実行します。

ConfigMap はシークレットに似ていますが、機密情報を含まない文字列の使用をサポートするように設計されています。ConfigMap オブジェクトは、Pod で使用したり、コントローラーなどのシステムコンポーネントの設定データを保存するために使用できる設定データのキーと値のペアを保持します。

参考文献

Security Context Constraints (SCC) を使用して、Pod のシステムでの受け入れを可能にするために (コンテナーのコレクションである) Pod の実行時に必要となる一連の条件を定義することができます。

以下は、SCC で管理できる分野の一部です。

必要なパーミッションがある場合は、デフォルトの SCC ポリシーの許容度を上げるように調整することができます。

参考文献

独自の継続的デプロイメント (CD) のツールを OpenShift Container Platform に統合することができます。

CI/CD および OpenShift Container Platform を利用することで、アプリケーションの再ビルドプロセスを自動化し、最新の修正の組み込み、テスト、および環境内の至るところでのデプロイを可能にします。

API は、スケーリング時にコンテナー管理を自動化する際に主要なロールを担います。API は以下の目的で使用されます。

参考文献

OpenShift Container Platform には、そのフレームワーク内に、TLS 証明書による暗号化を利用した REST ベースの HTTPS 通信を使用する複数のコンポーネントがあります。OpenShift Container Platform の Ansible ベースのインストーラーは、これらの認証をインストール時に設定します。以下は、このトラフィックを生成するいくつかの主要コンポーネントです。

openshift_master_named_certificates=[{"certfile": "/path/on/host/to/custom1.crt", "keyfile": "/path/on/host/to/custom1.key", "cafile": "/path/on/host/to/custom-ca1.crt"}]

OpenShift Container Platform はソフトウェア定義ネットワーク (SDN) を使用して、クラスター全体でのコンテナー間の通信を可能にする統一クラスターネットワークを提供します。

ネットワークの namespace を使用すると、Pod のネットワークを分離することができます。各 Pod には独自の IP およびバインドするポートの範囲が設定されるため、Pod のネットワークは相互に分離されます。異なるプロジェクトの Pod は、別のプロジェクトの Pod およびサービスとパケットの送受信をすることができなくなります。これを利用して、クラスター内の開発者環境、テスト環境、および実稼働環境を分離することもできます。

OpenShift Container Platform は、ルーターまたはファイアウォールのいずれかを使用して Egress トラフィックを制御する機能も提供します。たとえば、IP のホワイトリストを使用して、データベースのアクセスを制御できます。

参考文献

OpenShift Container Platform では、ユーザー、チーム、アプリケーション、および環境を分離するマルチテナントのクラスターを作成するために、単一のクラスター上でネットワークのトラフィックをセグメント化することができます。

たとえば、クラスター内でプロジェクトネットワークを分離するか、またはその逆も行う場合は、以下を実行します。

$ oc adm pod-network isolate-projects <project1> <project2>

上記の例では、<project1> および <project2> 内のすべての Pod とサービスは、クラスター内の他の非グローバルプロジェクトの Pod とサービスにはアクセスできず、その逆からもアクセスすることはできません。

コンテナーは、ステートレスとステートフルの両方のアプリケーションに役立ちます。割り当て済みのストレージを保護することは、ステートフルサービスのセキュリティーを保護する上で重要な要素になります。

OpenShift Container Platform は、NFS、AWS Elastic Block Stores (EBS)、GCE Persistent Disks、GlusterFS、iSCSI、RADOS (Ceph)、および Cinder を含む複数のタイプのストレージ向けのプラグインを提供します。送信中のデータは、相互に通信している OpenShift Container Platform のすべてのコンポーネントについて HTTPS 経由で暗号化されます。

PersistentVolume (PV) はストレージタイプでサポートされる方法でホスト上にマウントできます。異なるタイプのストレージにはそれぞれ異なる機能があり、各 PV のアクセスモードは、特定のボリュームによってサポートされる特定のモードに設定されます。

たとえば、NFS は複数の読み取り/書き込みクライアントをサポートしますが、特定の NFS PV は読み取り専用としてサーバー上でエクスポートされる可能性があります。各 PV には、ReadWriteOnce、ReadOnlyMany、および ReadWriteMany など、特定の PV 機能を説明したアクセスモードの独自のセットがあります。

参考文献

NFS、Ceph、および Gluster のような共有ストレージプロバイダーの場合、PV はグループ ID (GID) を PV リソースのアノテーションとして登録します。次に、Pod が PV を要求する際に、アノテーションが付けられた GID が Pod の補助グループに追加され、この Pod に共有ストレージのコンテンツへのアクセスを付与します。

参考文献

AWS Elastic Block Store (EBS)、GCE Persistent Disks、および iSCSI などのブロックストレージプロバイダーの場合、OpenShift Container Platform は SELinux 機能を使用し、権限のない Pod のマウントされたボリュームについて、そのマウントされたボリュームが関連付けられたコンテナーにのみ所有され、このコンテナーにのみ表示されるようにしてそのルートを保護します。

参考文献

本書の他のセクションで説明されているセキュリティー対策のほかにも、OpenShift Container Platform クラスターを監視および監査する機能は、不適切な利用に対してクラスターおよびそのユーザーを保護する上で重要な要素となります。

これに関連し、イベントとログという 2 つの主な情報源をクラスターレベルの情報として使用できます。

クラスター管理者は、関連するイベントを判別できるように イベント のリソースタイプについて理解し、イベントの一覧 を確認することをお勧めします。マスターコントローラーおよびプラグインの設定によっては、ここに一覧表示されているものよりも、多くのイベントタイプが使用される可能性があります。

イベントは、関連するリソースの namespace または デフォルト の namespace (クラスターイベントの場合) のいずれかの namespace に関連付けられます。デフォルト の namespace は、クラスターを監視または監査するための関連するイベントを保持します。 たとえば、これには ノード イベントおよびインフラストラクチャーコンポーネントに関連したリソースイベントが含まれます。

マスター API および oc コマンドは、イベントの一覧をノードに関連するものに制限するパラメーターを提供しません。これを実行する簡単な方法として grep を使用することができます。

$ oc get event -n default | grep Node
1h         20h         3         origin-node-1.example.local   Node      Normal    NodeHasDiskPressure   ...

より柔軟な方法として、他のツールで処理できる形式でイベントを出力することができます。たとえば、以下の例では NodeHasDiskPressure イベントのみを展開するために JSON 出力に対して jq ツールを使用しています。

$ oc get events -n default -o json \
  | jq '.items[] | select(.involvedObject.kind == "Node" and .reason == "NodeHasDiskPressure")'

{
  "apiVersion": "v1",
  "count": 3,
  "involvedObject": {
    "kind": "Node",
    "name": "origin-node-1.example.local",
    "uid": "origin-node-1.example.local"
  },
  "kind": "Event",
  "reason": "NodeHasDiskPressure",
  ...
}

リソースの作成や変更、または削除に関連するイベントも、クラスターの不正な使用を検出するために使用することができます。たとえば、以下のクエリーは、イメージの過剰なプルの有無を確認するために使用できます。

$ oc get events --all-namespaces -o json \
  | jq '[.items[] | select(.involvedObject.kind == "Pod" and .reason == "Pulling")] | length'

4

このセクションでは、クラスターで生成される運用ログの種類について説明します。

2017-10-17T13:12:17.635085787Z AUDIT: id="410eda6b-88d4-4491-87ff-394804ca69a1" ip="192.168.122.156" method="GET" user="system:admin" groups="\"system:cluster-admins\",\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="<none>" uri="/api/v1/nodes"
2017-10-17T13:12:17.636081056Z AUDIT: id="410eda6b-88d4-4491-87ff-394804ca69a1" response="200"

$ tail -5000 /var/log/origin/audit-ocp.log \
  | grep -Po 'response="..."' \
  | sort | uniq -c | sort -rn

   3288 response="200"
      8 response="404"
      6 response="201"

$ tail -5000 /var/log/origin/audit-ocp.log \
  | grep -Po ' user="(.*?)(?<!\\)"' \
  | sort | uniq -c | sort -rn | head -10

  976  user="system:openshift-master"
  270  user="system:node:origin-node-1.example.local"
  270  user="system:node:origin-master.example.local"
   66  user="system:anonymous"
   32  user="system:serviceaccount:kube-system:cronjob-controller"
   24  user="system:serviceaccount:kube-system:pod-garbage-collector"
   18  user="system:serviceaccount:kube-system:endpoint-controller"
   14  user="system:serviceaccount:openshift-infra:serviceaccount-pull-secrets-controller"
   11  user="test user"
    4  user="test \" user"