From a5cfa6615891f85a3a909f93f940d25c1ed3b60c Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Thu, 30 Jul 2020 07:08:49 +0900 Subject: [PATCH] change Node expression --- content/ja/docs/concepts/configuration/secret.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md index 103b8253a6..26ce98ab50 100644 --- a/content/ja/docs/concepts/configuration/secret.md +++ b/content/ja/docs/concepts/configuration/secret.md @@ -1123,11 +1123,11 @@ Secret APIへのアクセスが必要なアプリケーションは、必要なS Secretはそれを使用するPodとは独立に作成されるので、Podを作ったり、参照したり、編集したりするワークフローにおいてSecretが晒されるリスクは軽減されています。 システムは、可能であればSecretの内容をディスクに書き込まないような、Secretについて追加の考慮も行っています。 -SecretはNode上のPodが必要とした場合のみ送られます。 +Secretはノード上のPodが必要とした場合のみ送られます。 kubeletはSecretがディスクストレージに書き込まれないよう、`tmpfs`に保存します。 Secretを必要とするPodが削除されると、kubeletはSecretのローカルコピーも同様に削除します。 -同一のNodeにいくつかのPodに対する複数のSecretが存在することもあります。 +同一のノードにいくつかのPodに対する複数のSecretが存在することもあります。 しかし、コンテナから参照できるのはPodが要求したSecretのみです。 そのため、あるPodが他のPodのためのSecretにアクセスすることはできません。 @@ -1154,4 +1154,4 @@ Podに複数のコンテナが含まれることもあります。しかし、Po - アプリケーションはボリュームからSecretの値を読み取った後も、その値を保護する必要があります。例えば意図せずログに出力する、信用できない相手に送信するようなことがないようにです。 - Secretを利用するPodを作成できるユーザーはSecretの値を見ることができます。たとえAPIサーバーのポリシーがユーザーにSecretの読み取りを許可していなくても、ユーザーはSecretを晒すPodを実行することができます。 - 現在、任意のノードでルート権限を持つ人は誰でも、kubeletに偽装することで _任意の_ SecretをAPIサーバーから読み取ることができます。 - 単一のノードのルート権限を不正に取得された場合の影響を抑えるため、実際に必要としているNodeに対してのみSecretを送る機能が計画されています。 + 単一のノードのルート権限を不正に取得された場合の影響を抑えるため、実際に必要としているノードに対してのみSecretを送る機能が計画されています。