Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

機密性

 

現在のすべてのネットワークシステムでは、プラットフォームのユーザー名、パスワード、SSH キーなどの機密情報を処理する必要があります。Kubernetes 環境のポッドにも同じことが当てはまります。しかし、この情報を pod 仕様でクリアテキストとして公開すると、セキュリティーの問題が発生する可能性があり–ます。この問題を解決するには、少なくともクリアテキストの資格情報をできるだけ回避するツールまたは方法が必要です。

Kubernetes の機密オブジェクトはこの目的–に合わせて設計されており、すべての機密データをエンコードし、制御された方法でポッドに公開します。

Kubernetes シークレットの公式の定義は以下のとおりです。

「機密とは、パスワード、トークン、鍵などの少量の機密データを含むオブジェクトのことです。このような情報は、Pod 仕様または画像内に配置される場合があります。これを秘匿オブジェクトに配置することで、it がどのように使用されるかをより細かく制御し、偶発的な危険を軽減することができます」

ユーザーはシークレットを作成できます。また、システムでもシークレットが作成されます。シークレットを使用するには、pod がシークレットを参照する必要があります。

さまざまなタイプのシークレットがあり、それぞれが特定のユースケースに対応しています。また、さまざまな方法でシークレットを作成する方法も数多くあります。このガイドでは、シークレットの詳細については記載されていません。そのすべてをご確認いただくとともに、最新の変更をすべて記録するには、公式マニュアルを参照してください。

ここでは’、一般的に使用される機密タイプについてご紹介します。また、機密情報を作成する方法と、ポッドでシークレットを参照する方法についても学習します。セクションの最後に達すると、Kubernetes の機密オブジェクトの主なメリットと、それを活用してシステムのセキュリティを強化する方法を理解しておく必要があります。

まず’、次のような秘密の用語を見てみましょう。

  • 不透明: このタイプのシークレットは、任意のキーと値のペアを含むことができるため、Kubernetes’の観点からは非構造化データとして扱われます。その他すべてのタイプの機密情報は、常に一貫しています。

  • Kubernetes.io/Dockerconfigjson: このタイプの機密情報は、プライベートコンテナレジストリ (Juniper サーバーなど) との認証に使用され、独自のプライベートイメージを取得します。

  • TLS: TLS シークレットには、TLS 秘密鍵と証明書が含まれています。受信のセキュリティーを強化するために使用されます。第4章では、TLS シークレットの受信の例を示しています。

  • Kubernetes.io/service-account-token: Pod のコンテナで実行されているプロセスが API サーバーにアクセスする場合、特定のアカウントとして認証される必要があります (デフォルトでは、アカウントデフォルト)。Pod に関連付けられたアカウントは、サービスアカウントと呼ばれます。Kubernetes.io/service-account-token タイプのシークレットには、Kubernetes サービスアカウントに関する情報が記載されています。’本書では、この種の秘密とサービスアカウントについて詳しくは触れません。

  • 透過シークレット: タイプ固定型のシークレットは、任意のユーザー所有–のデータを表すので、通常、ユーザー名、パスワード、セキュリティ pin など、機密性の高い機密データを保存したいと考えています。そのため、機密性が確保されていることに気がついていることを知りたいと思います。

非透過シークレットの定義

まず、機密データの機密性を低くするには、’次のように base64 ツールを使用してエンコードしてみましょう。

次に、エンコードされたデータを機密の定義 YAML ファイルに挿入します。

また、-literal オプションを使用して、kubectl CLI との間で同じシークレットを直接定義することもできます。

いずれにしても、シークレットが生成されます。

透過シークレットを参照

次に、pod でシークレットを使用する必要があり、シークレットに含まれるユーザー情報が pod に送られます。前述したように、pod 内の不透明なシークレットを参照するにはさまざまな方法がありますが、その結果は異なっています。

通常、シークレットから実行されるユーザー情報は、次のいずれかの形式のコンテナに表示できます。

  • Files

  • 環境変数

’ここでは、シークレットを使用して、コンテナに環境変数を生成する例を示します。

次の YAML ファイルから pod とコンテナを生成します。

コンテナにログインし、生成された環境変数を確認します。

Base64 でエンコードされた元の機密データが、コンテナに存在するようになりました。

Dockerconfigjson Secret

Dockerconfigjson secret は、名前が示すように、通常は docker/config ファイルに保存されている Docker アカウントの認証情報を保持しています。Kubernetes ポッド内の画像は、プライベートコンテナレジストリを指している場合があります。その場合、Kubernetes はそのレジストリを使用してイメージを取得する必要があります。Dockerconfigjson タイプの secret は、この非常に目的に合わせて設計されています。

Docker 資格データ

Kubernetes.io/dockerconfigjson タイプのシークレットを作成する最も簡単な方法は、ログイン情報を kubectl コマンドで直接提供し、それによってシークレットを生成させることです。

シークレットの作成を確認します。

Note

作成したシークレットだけが、出力の最初の行だけになります。2行目は kubernetes.io/service-account-token タイプのシークレットで、contrail のセットアップが起動して実行されているときに、Kubernetes システムが自動的に作成します。

ここで、シークレットの詳細を確認します。

当然のこと’ですが、クリアテキスト形式の機密情報は一切表示されません。この出力には、key の値として非常に長いストリングがあることを示すデータ部分があります。dockerconfigjson. その外観は元のデータから変換されているように見えますが、少なくとも–機密性の高い情報を含んでいないため、シークレットを使用する1つの目的がシステムセキュリティの向上になります。

ただし、変換は暗号化ではなく、エンコードによって実行されるため、元の機密情報を手動で取得する方法はあります。dockerconfigjson を base64 ツールにパイプするだけで、元のユーザー名とパスワード情報が再び表示されます。

この出力では、以下の点についてハイライトしています。

  • Python-mjson. ツールは、デコードされた json データをフォーマットしてから端末に表示するために使用します。

  • 認証キーと値のペアがあります。与えられた認証情報 (ユーザー名とパスワード) に基づいて生成されるトークンです。

  • その後、このシークレットが装備されている場合、pod はこのトークンを使用して、ユーザー名とパスワードの代わりに、hub.juniper.net の Docker レジストリに基づいてそれ自体を認証し、Docker 画像を取得します。

Tip

ここ’では、データをシークレットオブジェクトから直接デコードする方法をもう1つ紹介しています。

こちらの --output=xxxxオプションは、kubectl get の出力をフィルタリングして、データにある dockerconfigjson の値のみが表示されるようにします。その後、この値は、デコードするオプション (-d のエイリアス) によって base64 にパイプされます。

このように手動で作成された docker レジストリシークレットは、1つのプライベートレジストリでのみ機能します。複数のプライベートコンテナレジストリをサポートするために、Docker credential ファイルからシークレットを作成できます。

Docker 資格ファイル (~/.Docker/config. json)

キーの名前として dockerconfigjson を作成すると、Docker 設定ファイルと同様の役割を果たします。docker/config. 実際には、このシークレットを Docker 構成ファイルから直接生成することができます。

Docker 認定資格情報を生成するには、まず、Docker 設定ファイルを確認します。

実際’には何もありません。設定の使用状況によっては、異なる出力が表示される場合がありますが、ここでは、新しいレジストリに docker ログインするたびに、この Docker 構成ファイルが自動的に更新されることを示します。

ファイル mydockerpass .txt は、ユーザー名 JNPR-FieldUser213 のログインパスワードです。パスワードをファイルに保存し、それを docker login コマンドに渡すと、--password-stdin オプションには、シェル履歴でパスワードクリアテキストが公開されないというメリットがあります。

Tip

パスワードを直接書き込むことができれば、これは安全ではないというわかりやすい警告が表示されます。

これで、Docker の認証情報が更新された config.json拡張子

ログインプロセスによって、 config.json認証トークンを保持するファイル。S’を使用して、 .docker/config.json拡張子

YAML ファイル

また、サービスや受信などの他のオブジェクトを作成する場合と同じ方法で、YAML ファイルから直接シークレットを作成することもできます。

のコンテンツを手動でエンコードするには .docker/config.json拡張子

その後で、base 64 エンコード値 .docker/config.jsonファイルは YAML ファイルの下のデータとして、以下のようになります。

Base64 は暗号化–ではなくエンコードに関するものであることに注意してください。これはプレーンテキストと同じであると見なされます。そのため、このファイルを共有することで、シークレットが危険にさらされます。

ポッドのシークレットを参照

作成されたシークレットは、プライベートレジストリからイメージを取得するために pod/rc またはデプロイメントによって参照できます。シークレットを参照するには、さまざまな方法があります。このセクションでは、pod spec で imagePullSecrets を使用してシークレットを参照する方法をご確認ください。

ImagePullSecret は、Docker (またはその他の) イメージレジストリパスワードを含むシークレットを kubelet に渡す方法で、pod の代わりにプライベートイメージを取得できます。

プライベートリポジトリから Juniper cSRX コンテナをプルするポッドを作成します。

ここで、pod を生成します。

CSRX は動作しています。

そして背後では、pod はプライベートレジストリに対して自己認証を行い、画像を取得して、cSRX コンテナを起動します。

このテストで見たように、共有オブジェクトはポッドとは別に作成されます。また、オブジェクト仕様を確認しても、機密性の高い情報が画面上に直接提供されるわけではありません。

機密情報がディスクに書き込まれることはありませんが、その代わりに、必要なノード上でのみ、tmpfs ファイルシステムに保存されます。また、シークレットは、依存している pod が削除されたときにも削除されます。

ほとんどのネイティブ Kubernetes ディストリビューションでは、ユーザーと API サーバー間の通信は SSL/TLS によって保護されています。そのため、これらのチャネル経由で送信される機密情報は、適切に保護することができます。

任意のポッドは、別のポッドによって使用されるシークレットにアクセスできません。これにより、異なるポッド間の機密データのカプセル化が容易になります。ポッド内の各コンテナは、そのボリュームがコンテナ内に表示されるように、ボリュームの機密を要求する必要があります。この機能を使用して、ポッドレベルでセキュリティーパーティションを構築できます。