SGTM。 @ kubernetes / kubectlこれについて何か考えはありますか？

不合理ではありませんが、ユーザー入力を制御するためにポッドセキュリティポリシーが必要であり、おそらく名前でユーザーを禁止する必要があります（コンテナでは許可されていないため、UIDを指定する必要があります）。

@stttsおよび@ncdcreexec

正当なユースケース

これに関する更新はありますか？

私のアプリコンテナイメージは、ビルドパックを使用してビルドされています。 シェルを開きたいのですが。 私がそうするとき、私はルートであり、すべてのenv変数が設定されます。 しかし、ビルドパックで生成された環境はありません。 アプリユーザーのログインシェル（ su -l u22055 ）を開くと、アプリ環境がありますが、kubernetesenvvarsがありません。

su -lはenv変数をコピーしなかったと思いましたか？ 明示的にコピーする必要があります
自分で、または別のコマンドを使用してください。

2016年10月11日火曜日午後5時26分、MichaelElsdörfer< [email protected]

書きました：

私のアプリコンテナイメージは、ビルドパックを使用してビルドされています。 開封したい
シェル。 私がそうするとき、私はルートであり、すべてのenv変数が設定されます。 しかし
buildpackで生成された環境はありません。 ログインシェルを開くと
アプリユーザー（su -l u22055）私は自分のアプリ環境を持っていますが、今は
kubernetesenvvarsがありません。

—
あなたは言及されたチームに所属しているので、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/30656#issuecomment -253085398、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABG_p7sIu20xnja2HsbPUUgD1m4gXqVAks5qzCksgaJpZM4Jk3n0
。

@ miracle2k - su -m -l u22055を試しましたか？ -mは、環境変数を保持することになっています。

@adarshaj@ smarterclaytonヒントをありがとう。 su -mには独自の問題があります（ホームディレクトリが間違っています）が、それまでは機能させました。 ただし、重要なのは、「kubectlexec」が正しいことを実行することを望んでいるということです。 Dockerファイルで定義されているユーザーを使用することもできます。

これが私がこの機能を必要とする方法の例です。

公式のJenkinsイメージは、ユーザーJenkinsとして実行されます。 サイズを変更する必要がある永続ディスクが接続されています。 kubectlに--userがある場合、rootおよびresize2fsとしてbashすることができます。 残念ながら、それがなければ、それは非常に苦痛です。

追加のユースケース-あなたはセキュリティを意識しているので、コンテナ内で実行されているすべてのプロセスに特権がありません。 しかし、今は予期せず何かが機能しておらず、rootとしてアクセスして、たとえばデバッグユーティリティをインストールし、ライブシステムの何が問題になっているのかを把握したいと考えています。

デバッグ目的でのインストールも私のユースケースです。 現在、kubernetesを実行しているノードにsshを入力し、 docker execを直接使用しています。

これの状況はどうですか？ この機能は非常に便利です

チェックしませんでしたが、 --asと--as-groupのグローバルフラグはここで役立ちますか？ 彼らはexecでも動作しますか？ cc @liggitt

チェックしませんでしたが、-asおよび--as-groupグローバルフラグはここで役立ちますか？ 彼らはexecでさえ働きますか？ cc @liggitt

いいえ、それらはkubernetes APIに対して自分自身を識別することと関係があり、exec呼び出しのために選択されたuidに通知するために通過することはありません

ユーザーフラグがないのは面倒です。 ユースケースは、非特権ユーザーとして実行されるコンテナーがあり、そのコンテナーにボリュームをマウントしますが、ボリュームフォルダーはユーザーによって所有されていません。 指定された権限でボリュームをマウントするオプションはありません。 エントリポイントスクリプトを使用してアクセス許可を変更することはできません。これは、非特権ユーザーとして実行されるためです。 特権のないユーザーとしても実行されるため、lifecycle.preStartフックを使用できません。 '-u'オプションが存在する場合、 kubectl exec -u rootはそれを行うことができます。

コンテナユーザー以外の「exec」を許可/ブロックするには、これは追加のRBAC権限である必要があると思います。

理想的には、lifeCycleフックは、コンテナーが実行されない場合でも、コンテナー内でルートとして実行できる必要があります。 現在のところ、最善の代替策は、おそらく同じマウントに対してinitコンテナを実行することです。 コンテナの起動時にrootとして1行のコマンドが必要な場合に、別のコンテナを起動してボリュームをマウントするための一種のオーバーヘッド。

/ sig cli

この機能の+1。 これがないと、デバッグが非常に困難になります。

この機能の+1。 Dockerコンテナを再構築し、Dockerファイルの最後の行にUSER rootが含まれていることを確認してから、デバッグしてから、これを無効にする必要があります。

dockerコマンドラインに--userフラグがあるようです

johnjjung、ノードへのsshアクセスがある場合は、dockerとuserフラグを使用してコンテナーに接続できます。これにより、時間を少し節約できる可能性があります。

うーん、すごいこれを試してみよう

2017年7月10日、11：34 -0400、 BenAbineriBubblenotifications @github.comは次のように書いています。

johnjjung、ノードへのsshアクセスがある場合は、dockerとuserフラグを使用してコンテナーに接続できます。これにより、時間を少し節約できる可能性があります。
—
コメントしたのでこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

+1は本当に問題です、私はsshを実行してから、dockerexecを実行する必要があります。

/ cc @frobware

+1してください。 回避策としてdockerexec-uを使用しないでください。

+1-kubectl execは、docker execに比べて大幅な時間の節約になるため、ユーザーを指定するためにdockerexecに戻らなければならないたびに泣きます。

考慮事項：

• uidはCRIのexecインターフェイスの一部である必要があり、すべてのランタイムがそれをサポートする必要があります
• 承認チェックがuidのポッドセキュリティポリシー制限で何になるかを理解する必要があります

+1は、残念ながら私たちが習慣にしてきた安全でない回避策を防ぐためです（つまり、runAsUserをrootに設定し、publicをデプロイするときに値を元に戻すのを忘れます😮）。

+1

+1私にとっては、ポッドにログインして、実行ユーザーとしてrootを使用してコンテナーを再デプロイせずに変更を加えるには、-userフラグが本当に必要です。

この問題はかなり強力にサポートされているようですが、優先順位を付けるためにできることはありますか？ （はい、はい、パッチは受け入れられました:)）

定義されたユーザーで実行するこの機能を持つと便利な+1

これの実装はセキュリティ上の懸念から難しいかもしれないと思いますか？ たとえば、Dockerfileが最初に非rootユーザーとして設定されていた場合、今すぐrootユーザーとしてコマンドを実行できるようにする必要がありますか？ --dockerのユーザーフラグはこれをどのように処理しましたか？ 彼らがそれを適切に処理した場合、これを渡すためにkubectlexecコマンドにパッチを当てる必要があると思います。

これが適切な戦略であるかどうか誰かに教えてもらえますか？ それから私はPRを始めることができます

@johnjjungはい、ここでの戦略は、docker--userフラグを渡すためにkubectlexecにパッチを適用することだと思います。

また、kubectlから接続するためにGCPからの暗黙的な認証があるため、セキュリティ上の懸念は軽微なようです。

また、kubectlから接続するためにGCPからの暗黙的な認証があるため、セキュリティ上の懸念は軽微なようです。

どうして？ ポッド仕様で許可されるユーザーを制御できます。 exec呼び出しで指定されたすべてのユーザーIDに対して同等の制御を期待します。 元のコンテナが実行されなかったときにexecをrootとして実行できるかどうかについて、同様の質問があります。 もしそうなら、ポッドセキュリティコンテキストとポッドセキュリティポリシーコントロールがこの新しいオプションにどのように適用されるかを考えずにそれを公開することはできません

@liggittこれは、Dockerfile自体にユーザーを設定するのと同じですが、Dockerのユーザーフラグを使用してrootとして実行できます。

Dockerの主な関心事は、侵害された場合に、_running_コンテナ内からのルートアクセスを防止することであるようです。 ある時点で、ユーザーがツールを実際に開発して操作できるようにするために、信頼を与える必要があります。

たとえば、Dockerfileが最初に非rootユーザーとして設定されていた場合、今すぐrootユーザーとしてコマンドを実行できるようにする必要がありますか？ --dockerのユーザーフラグはこれをどのように処理しましたか？

@johnjjung @ jordanwilson230が言うように、dockerランタイム引数はDockerfileディレクティブをオーバーライドします。 私の頭から離れて、これはほとんどの実行時引数（ポート番号など）がどのように機能するかです。

元のコンテナがなかったときにexecをrootとして実行できるかどうかについて同様の質問があります

@liggitt明確にするために、ポッド仕様で定義されたユーザーIDの役割は変更されず、意図した効果を継続します。 コンテナ（およびそのプロセス）は、そのユーザーとして起動されます。 ここで提起された問題は、（すでに）認証されたユーザーが、主にデバッグ目的で、rootまたは任意のユーザーで実行する手動オプションを許可することでした。

ここで提起された問題は、（すでに）認証されたユーザーが、主にデバッグ目的で、rootまたは任意のユーザーで実行する手動オプションを許可することでした。

そして私のポイントは、ユーザーがrootとしてコンテナーを実行するのを防ぐために今日持っているコントロールは、rootで実行されないようにするためにここでも適用する必要があるということです。

@liggitt申し訳ありませんが、より明確な方法で説明する方法がよくわかりません。 上記のコメントに関して、これを試してください：

• ポッドを実行しているノードにSSHで接続します（私のポッドはKafkaを実行しており、kafkaユーザーもpod.specで設定されています）
  jordan@gke-my-default-pool-dsioiaag-i9f3 ~ $ docker exec -it -u root myKafkaContainer bash root@kafka-0:/# echo "I've exec'd into my container as $(whoami) despite defining the kafka user in pod.spec...." I've exec'd into my container as root despite defining the kafka user in pod.spec.... root@kafka-0:/#
  これがGKEの観点からすでに可能であることを確立した後（非常に厄介な方法ではありますが）、どのような新しいセキュリティ上の懸念を考えていますか？ この問題は車輪の再発明ではなく、利便性を提供することです。

これがGKEの観点からすでに可能であることを確立した後（非常に厄介な方法ではありますが）、どのような新しいセキュリティ上の懸念を考えていますか？

問題は、現在存在しないkubernetesAPIを介して電力を公開することです。 ユーザーがAPIを介してワークロードを実行することを許可され、ノードへのsshアクセスを許可されないのは通常のことです。

次の場合に限り、APIを介して機能することは素晴らしいことです。

1. クラスタ管理者は、ポリシーを介して許可されているかどうかを制御できます
2. ポリシーの表現方法は、既存のポリシーと一貫性があります（この場合、理想的には、同じPodSecurityPolicyメカニズムに基づいて実行されます）。
3. 新しい機能は、以前に保護されたシステムに穴を開けません（デフォルトはオフ、または既存のポリシーに基づいてゲートされます）

@liggitt絶対に正しいです。 したがって、セキュリティへの影響の範囲を_node_アクセスに絞り込んだので、私たち（ @johnjjungなど）はついにこの議論を実用的な実体に使用し始めることができます。 GKEプラットフォームでrootとして実行するためのkubectlプラグインを開始しました。 AWSなどにたどり着くまでには少し時間がかかります。 @johnjjungあなたはまだあなたの側で拾う気がありますか？

@liggittあなたが行った編集を見ただけで、これを進めるのに役立ちます。 ありがとう。

関連する議論については、既存のポッドで個別に指定されたユーザーIDを含む任意のコンテナーを実行できるようにする提案を参照してください-https://github.com/kubernetes/community/pull/1269

実行したいもののセキュリティ面が元のコンテナから離れるほど、仕様全体をコヒーレントコンテナとして既存のアドミッションメカニズムで検証できることが重要になります。

@ jordanwilson230コードベースを確認していると、kubectl execコマンドの統合のポイントが見つかりました。これは良い出発点です。他のkubernetesコードベースで、Dockerを許可できる場所を変更する必要があるかどうかわかりません。 uフラグ。 そうは言っても、どこかから始めて、クラスター管理者やポッドのセキュリティポリシーなどでこの問題に戻ることができると思います...一度に1ステップずつ。

kubernetesがdocker --userフラグを実行する場所を変更する場所を誰かが知っている場合は、それが役立ちます。

こんにちは@johnjjung。 昔々（<1.6）、Kubernetes kubeletsはDockerを直接使用し、このようなオプションを渡すことができました。 現在、複数のランタイム、CRIをサポートするための標準インターフェースがあります。 Dockerのように、ランタイムに渡すことができる命令を決定するのはCRIの機能です。

Kubernetesは、さまざまなコンテナランタイム（ dockershim + Docker + containerd 、 cri-containerd + containerd 、rkt、cri-o、lxd、Fraktiなど）に何をするかを指示しますCRIインターフェースを使用してください。 cri-oランタイム実装の場合は直接、またはdockershimやcri-containerdのようなシムを介して。 したがって、ここで必要なことを実行できるようにするには（コンテナーが開始されたときとは異なるユーザーとして実行されている既存のコンテナーにプロセスを追加する）、最初にそのオプションをサポートするようにCRI仕様を拡張する必要があります（たとえば、 ExecSyncにはuidオプションが必要であり、 LinuxContainerSecurityContextはそれを禁止する必要はありません。 @ liggittは上記と同じように言ったと思います）。

次に、各コンテナーランタイムまたはランタイムシムは、先に進んでそのサポートを実装できます。 Dockerの場合、これはCRI仕様/インターフェースへの追加をサポートするためにdockershim実装を拡張することを意味します。 ただし、 dockershim + Dockerは廃止され、今後数回のリリースでcri-containerd + containerdが優先されると予想されるため、おそらくcri-containerdに焦点を当てたほうがよいでしょう。

http://blog.kubernetes.io/2017/11/containerd-container-runtime-options-kubernetes.html

https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md

デバッグコンテナの提案として、この議論にも関連しています。 新しいkubectl debugコマンドを使用して、同じポッドスペースで2番目のコンテナイメージを実行できるようにする必要があります。 おそらく、追加のコンテナを別のユーザーとして実行できますか？

@whereisaaronあなたの投稿は大きな助けになります。 それをすべて詳しく書いてくれてありがとう。

@whereisaaron詳細をありがとう。 私があなたを理解しているなら、デバッグの提案（それが通過した場合）は、これを一日の終わりに置くのに最適な場所かもしれないようです。 作業が承認されたかどうかはわかりませんが、基本的には、選択したコンテナーをそのポッドにアタッチして、そのポッドをデバッグできます（これは素晴らしいサウンドです）が、元のコンテナー内でユーザーを変更することはできますか？ また、cri-containerdを使用してパッチを待つか、先に進む必要があるということですか？

これがまだ実装されていない理由の1つは、複数のグループがさまざまな領域で作業している複数のリポジトリがあるためと思われます。

@johnjjungデバッグコンテナは、Kubernetes 1.9で「アルファ」機能として実装することが承認されていると思います（この機能を明示的に有効にしない限り、オフになっています）。 でも1.9になったとは思いません。 したがって、おそらく1.10以降になるまではありません。

私が理解しているように、デバッグコンテナは、「デバッグ中」のターゲットポッド内のプロセスとして実行されるため、ポッドと同じカーネルセキュリティコンテキストにあり、独自のコンテナイメージ/ファイルシステムを持っています。 したがって、任意のプロセスをデバッグし、ポッドにある任意のボリュームをマウントできます。 しかし、あなたは同じセキュリティコンテキストにいるので、ポッドで使用できるuidに同じカーネルが課した制限に固執しているのではないかと思います。 そこにはわかりません。それに取り組んでいる＃sig-nodeの人々に尋ねる必要があります。

CRIの拡張に関しては、これを行うには＃sig-nodeからの多くのサポートが必要だと思います。さらに、 cri-containerdやcri-oなどのさまざまなランタイムプロジェクトからの異議はありません。次に、サポートを実装する必要があります。

今日はあまり時間がありませんが、GKEで実行しているユーザーのために、ユーザー[-u]フラグを使用して実行するためのアドホックkubectlプラグインを作成しました。

https://github.com/jordanwilson230/kubectl-plugins

インストールスクリプトを実行して、そのプラグインまたはそれらすべてを自由に変更/コピーしてください。 @johnjjungや他の人たちがもっと取り組むことができるようになるまでは、ただのアドホックな解決策です。

GCPに固有ではない代替ソリューションを用意します。 これはSSHをまったく使用せず、kubectlが機能する必要があるだけです。

https://github.com/mikelorant/kubectl-exec-user

kubectl-exec-userのポッドは、それを使用しているユーザーがシェルインを要求されているコンテナーにアクセスできることを確認しますか？

これは、kubernetesAPIが許可するアクセスにフォールバックします。 RBACがコンテナにノードドッカーソケットのマウントを許可している場合にのみ機能します。

SSHを必要とせずに、コンテナーからノードにブレークアウトするための創造的な方法を私のソリューションと考えてください。 すべて同じセキュリティ条件を考慮する必要がありますが、少なくともkubernetesAPIサーバーの制限を尊重します。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleを使用して、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /closeを使用して解決してください。

sig-testing、kubernetes / test-infra、 fejtaにフィードバックを送信します。
/ lifecycle stale

/ remove-lifecycle stale

これは大歓迎です。 セキュリティを意識し、すべてのプロセスを非ルートとして実行したことで罰せられるのはクールではありません。 （https://github.com/kubernetes/kubernetes/issues/30656#issuecomment-272055993の言い換え）

/sigノード

この機能にはリベースが必要な未完成のPRがあるようです： https：//github.com/kubernetes/kubernetes/pull/59092。 それを手に取って完成させることができる人はいますか？ CC @louyihua

+1
（ @SimenBと同じ問題が発生します-デバッグ目的でインストールしたいのですが、「Dockerを直接使用する」ヒントをありがとうございます）

これが適切にサポートされるのを待っている間、中間の解決策は、 su-exec （DockerfileまたはK8sマニフェストのいずれか）でdockerCMDを実行することです。 su-execの重量はわずか20k（アルパイン上）であり、このようにして、アプリはkubectl execにルートを持ちながら、特権なしで実行されます。

+1

このような-uフラグもいただければ幸いです。 +1。

ただのアイデア：

たとえば、 --conainer-typeのようなものは、サポートされている引数を下にあるコンテナの実装に直接渡すことができるようにするための大きなプラスになります。

kubectl exec --container-type=docker -it -u 0 NAME

これにより、kubectlにコンテナランタイムの基盤となる機能のサブセットのみが含まれることを回避できます。 さらに、サポートされているすべてのコンテナータイプについて、サポートされている引数をkubeletレイヤーからコンテナーに至るまでマッピングおよび抽象化する必要がないため、労力を節約できます。

したがって、要約すると、 --container-typeフラグがないと、kubectlから抽象化された引数のみを使用でき、基になるコンテナタイプは完全に透過的です。 フラグを使用すると、コンテナ固有の引数を渡すことができます。 コンテナタイプにバインドするかどうかは、kubectlのユーザー次第です。

ところで：ノードにSSHで接続し、Dockerを直接使用するためのヒントを提供してくれた@SimenBに感謝します。 それは私の問題を一時的に解決しました。 Minikubeを使用して、rootとしてログインするために次のことを行うことができました。
minikube ssh "docker exec -it -u 0 <container-id> bash"
多分これは誰かの助けになるかもしれません。

不快なものを自動化する回避策スクリプト。 必要なノードへのSSHアクセス。

使用法：

`` `./shell-into-pod-as-root.sh[シェル]
./shell-into-pod-as-root.sh podname
./shell-into-pod-as-root.sh podname sh

Enjoy!

！/ usr / bin / env bash

set -xe

POD = $（kubectl describe pod "$ 1"）
NODE = $（echo "$ POD" | grep -m1 Node | awk -F'/''{print $ 2}'）
CONTAINER = $（echo "$ POD" | grep-m1'コンテナID'|awk -F'docker：//''{print $ 2}'）

CONTAINER_SHELL = $ {2：-bash}

+eを設定します

ssh -t "$ NODE" sudo docker exec --user 0 -it "$ CONTAINER" "$ CONTAINER_SHELL"

if ["$？" -gt 0]; それから
+xを設定
ポッドへのSSHのエコーに失敗しました。 「$PATHに実行可能ファイルが見つかりません」のようなエラーメッセージが表示された場合は、次のことを試してください。
エコー"$0 $ 1 sh"
fi
`` `

@Nowaker名前空間をどのように処理しますか？

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleを使用して、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /closeを使用して解決してください。

sig-testing、kubernetes / test-infra、 fejtaにフィードバックを送信します。
/ lifecycle stale

/ remove-lifecycle stale

このような-uフラグもいただければ幸いです。 +1。

ただのアイデア：

たとえば、 --conainer-typeのようなものは、サポートされている引数を下にあるコンテナの実装に直接渡すことができるようにするための大きなプラスになります。

kubectl exec --container-type=docker -it -u 0 NAME

これにより、kubectlにコンテナランタイムの基盤となる機能のサブセットのみが含まれることを回避できます。 さらに、サポートされているすべてのコンテナータイプについて、サポートされている引数をkubeletレイヤーからコンテナーに至るまでマッピングおよび抽象化する必要がないため、労力を節約できます。

したがって、要約すると、 --container-typeフラグがないと、kubectlから抽象化された引数のみを使用でき、基になるコンテナタイプは完全に透過的です。 フラグを使用すると、コンテナ固有の引数を渡すことができます。 コンテナタイプにバインドするかどうかは、kubectlのユーザー次第です。

ところで：ノードにSSHで接続し、Dockerを直接使用するためのヒントを提供してくれた@SimenBに感謝します。 それは私の問題を一時的に解決しました。 Minikubeを使用して、rootとしてログインするために次のことを行うことができました。
minikube ssh "docker exec -it -u 0 <container-id> bash"
多分これは誰かの助けになるかもしれません。

ええ-dockerexecを使用してこれを行うのは簡単です-それは主に一貫性に関するものです-マルチユーザーdockerコンテナーは実際には少し冗談です-VMをコンテナーに変換することからの遺産です。

私は現在、これをgrafanaで扱っています-これは時間とともに経過すると思います。

@bryanhunteslノードへの手動SSH接続を必要としない回避策についての説明があります。 このプラグインを試すこともできます-https：//github.com/jordanwilson230/kubectl-plugins

ユーザーがノードにSSHで接続できるようにしたくない場合はどうなりますか？ ユーザーにノードへのsshアクセスを許可すること、およびユーザーにdockerへのアクセスを許可することは、セキュリティ上のリスクになる可能性があります。 Dockerは、名前空間やk8s権限について何も知りません。 ユーザーがdocker execを実行できる場合は、_any_名前空間のポッドに実行できます。

SSHは適切なソリューションではありません、私見。

ユーザーがノードにSSHで接続できるようにしたくない場合はどうなりますか？ ユーザーにノードへのsshアクセスを許可すること、およびユーザーにdockerへのアクセスを許可することは、セキュリティ上のリスクになる可能性があります。 Dockerは、名前空間やk8s権限について何も知りません。 ユーザーがdocker execを実行できる場合は、_any_名前空間のポッドに実行できます。

SSHは適切なソリューションではありません、私見。

私はその意見を2番目に-直接アクセスを得るために帯域外メカニズムを使用することは潜在的な攻撃領域を増やしています。

ユーザーがノードにSSHで接続できるようにしたくない場合はどうなりますか？ ユーザーにノードへのsshアクセスを許可すること、およびユーザーにdockerへのアクセスを許可することは、セキュリティ上のリスクになる可能性があります。 Dockerは、名前空間やk8s権限について何も知りません。 ユーザーがdocker execを実行できる場合は、_any_名前空間のポッドに実行できます。

SSHは適切なソリューションではありません、私見。

SSH@gjcarneiroを必要としないソリューションがあります。 また、ユーザーは、ノード（GCPの場合）@bryanhunteslへのSSHアクセスを許可する前に、まずパブリックSSHキーをComputeMetadataに追加する必要があります。

@liggittこのトピックが始まってから3年が経ちましたが、結論はありますか？

この解決策が以前に言及されているかどうかはわかりませんが、回避策として行ったのは、すべてのコンテナーに、正しいユーザーとしてログインするスクリプトを含めることです。 プラスmotd：

Dockerfile：

USER root
RUN echo "su -s /bin/bash www-data" >> /root/.bashrc
# this exit statement here is needed in order to exit from the new shell directly or else you need to type exit twice
RUN echo "exit" >> /root/.bashrc
# /var/www is www-data's home directory
COPY motd.sh /var/www/.bashrc

motd.sh：

RED='\033[0;31m'
YELLOW='\033[0;33m'

echo -e "${RED}"
echo "##################################################################"
echo "#        You've been automatically logged in as www-data.        #"
echo "##################################################################"
echo -e "${YELLOW} "
echo "If you want to login as root instead:"
echo -e "$(if [ "$KUBERNETES_PORT" ]; then echo 'kubectl'; else echo 'docker'; fi) exec -ti $(hostname) -- bash --noprofile -norc"

TEXT_RESET='\033[0m'

echo -e "${TEXT_RESET} "

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleを使用して、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /closeを使用して解決してください。

sig-testing、kubernetes / test-infra、 fejtaにフィードバックを送信します。
/ lifecycle stale

/ remove-lifecycle stale

[exec-as] kubectlプラグインを使用します：

kubectl krew install exec-as

上で述べたように、これには本当にKEPとセキュリティへの影響についての議論が必要です。 必ずしも悪い考えではありません。システムに大きな影響を与えるだけで、コーディングを開始する前に設計が必要です。

このためのKEPのレビューと羊飼いを喜んでお手伝いしますが、確かにいくつかの落とし穴があり、しばらく時間がかかる場合があります。

@ miracle2k - su -m -l u22055を試しましたか？ -mは、環境変数を保持することになっています。

@ miracle2kこの(trying to exec as root user)を試しましたが、 No passwd entry for user '0'を取得しました

$ su -m -l 0
No passwd entry for user '0'

こんにちは。 この問題を解決するために、私は「kpexec」CLIを開発しました。
フィードバックをお寄せください。

• https://github.com/ssup2/kpexec

ポッドを実行するノード：

docker exec -u 0 -it \
    `kubectl -n NAMESPACE get pod \
          -l label=value \
          -o jsonpath='{range .items[*].status.containerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3` \
sh

@cristichiru私が操作したほとんどのクラスターでは、基盤となるノードへの直接のシェルアクセスはありません。 他の人にもそうなることが多いのではないかと思います。

そのような場合、ここで提示されている他のオプション（kubectlプラグインなど）が唯一の方法である可能性があります-dockerデーモンにもアクセスできないと仮定します。

+1

KEPテンプレートはこちらhttps://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

私はそれを書くのにどれだけの作業が必要かを理解したと思いました...ええ、私はこれを書く人ではありません、テンプレートはチェックリスト項目1で私を失いました**Pick a hosting SIG.**プロセスに精通している人は誰でも欲しいドラフトを開始するには？ 👍をアクティブなKubernetesユーザーとしての提案をサポートする場所が欲しいだけです。

これはばかげているように聞こえるかもしれませんが、この問題に対する約5ダースの適切にコード化/スクリプト化/記述された回避策があるので、私よりも提案された技術的解決策を起草するのに適した立場にある人々がいることは明らかです。

Kubernetesが新しいOpenStackになり、 PROCESSのおかげで妥当な時間枠で何も達成できないように感じます。

ここでの@VikParuchuriの元のユースケースは、コンテナー自体が信頼できないユーザーとして実行されている場合でも、コンテナーをrootとしてデバッグ/トラブルシューティングできるようにすることです。 良いユースケースです。解決すると、root以外のユーザーとしてコンテナーを実行するようになります。 🎉

docker execのKEPを準備する前に、 k8sエフェメラルデバッグコンテナがこのユースケースに対応していないことを簡単に確認してください。

docker exec --userは、そのユースケースに対処する唯一の方法であり、使用されているDockerランタイムに依存しています。 k8sがcontainerdに移行すると、 dockerdとその友達はオプションであるか、インストールされていないため、将来を見据えたオプションではない可能性がありますか？

このユースケースに対処するもう1つのk8sネイティブの方法は、エフェメラルデバッグコンテナです。 信頼できないユーザーとして実行されているコンテナがあるとします。 デバッグコンテナを使用すると、ターゲットコンテナと同じプロセススペースで一時コンテナを開始できますが、root（または誰でも）として実行できます。 このアプローチには、execアプローチに比べていくつかの重要な利点があります。特に、必要なデバッグツールとユーティリティをデバッグコンテナのイメージに含めることができます。 したがって、実行する必要がある場合に備えて、utilsやeditorsなどでターゲットコンテナイメージを肥大化させる代わりに（🐑..、有罪！）、代わりに素敵な大きなスイスアーミーナイフのデバッグコンテナイメージを作成して、アプリケーションイメージをクリーンに保つことができます。 ターゲットにshしかない場合は、デバッグコンテナでbashを使用できます。 単一のバイナリコンテナやディストロレスコンテナのように、実行するシェルがまったくないコンテナをデバッグすることもできます。

たとえば、 busyboxを使用して、コンテナをルートとしてデバッグします。

kubectl alpha debug -it ephemeral-demo --image=busybox --target=ephemeral-demo

これは、コンテナを分離されたプロセスとして扱い、デバッグのために「アタッチ」して、シェル化するミニVMのようにするという点で、間違いなく優れたモデルだと思います。 欠点は、外部マウントまたは「空の」マウントを共有できない限り、ターゲットのファイルシステムを検査できないことです。 プロセスの名前空間をターゲットと共有するため、 /proc/$pid/rootを介してターゲットコンテナのファイルシステムにアクセスすることもできます。

エフェメラルデバッグコンテナはすでにプロセスをナビゲートし、実装されています:-)。 〜1.16および1.18 kubectlにはalpha debugコマンドが含まれているため、これらのコンテナはアルファ版です。 詳細はこちら：

参照：

• https://medium.com/01001101/ephemeral-containers-the-future-of-kubernetes-workload-debugging-c5b7ded3019f
• https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral -container
• https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/
• https://www.shogan.co.uk/kubernetes/enabling-and-using-ephemeral-containers-on-kubernetes-1-16/

思いやりのある返信をありがとう@whereisaaron :)私はそれが物事を非常にうまく捉えていると思います。

私はそれを書くのにどれだけの仕事が必要かを理解するだろうと思いました...ええ、私はこれを書く人ではありません、テンプレートはチェックリスト項目1で私を失いましたホスティングSIGを選んでください。 プロセスに精通している人はドラフトを開始したいですか？ 👍をアクティブなKubernetesユーザーとしての提案をサポートする場所が欲しいだけです。

KEPは非常に困難な場合がありますが、KEPの周りに少しコンテキストを提供したいと思います。 Kubernetes自体は非常に大きいです。 潜在的な変更は、貢献者ベースとユーザーの両方にとって非常に大きな爆風半径を持っています。 新しい機能は簡単に実装できるように見えるかもしれませんが、両方のグループに広く影響を与える可能性があります。

コードベースの一部の管理をSIGに委任します。 また、KEPを介して、1つ以上のSIGが機能についてコンセンサスを得ることができます。 機能の機能に応じて、APIレビューを経たり、スケーラビリティの問題などを評価したりする場合があります。

これはすべて、生産されたものが成功する可能性が最も高く、SIGが喜んでそれをサポートする方法で開発されることを保証することです。 元の作者が離れた場合、それを維持する責任はSIGにあります。 たとえば、機能が安定版にプロモートされてから非推奨のフラグが立てられた場合、非推奨ポリシーに従って削除できるようになるまでには、最低1年かかります。

機能に対する十分な需要がある場合、通常、KEPプロセスに精通している誰かが、それを実行し、それを実行するのを支援することを提案しますが、それでもそれを駆動する誰かが必要です。

いずれにせよ、機能をマージすることに関連するプロセスがある理由について、少なくとも少し光を当てることを願っています。 ：+1：ご不明な点がございましたら、お気軽に直接お問い合わせください。

欠点は、外部マウントまたは「空の」マウントを共有できない限り、ターゲットのファイルシステムを検査できないことです。

私にとって、ファイルシステムをルートとして検査し、ファイルシステムとルートとして対話できるユーティリティを実行することが、要求された機能のサポートを取得したい最大の理由です。 要するに、この提案は私の問題をまったく解決しません。

欠点は、ターゲットのファイルシステムを検査できないことです。

挿入されたデバッグコンテナはプロセス名前空間をターゲットコンテナと共有するため、デバッグコンテナからターゲットコンテナ内の任意のプロセスのファイルシステムにアクセスできます。 これには、コンテナファイルシステムとそれらのコンテナにマウントされているファイルシステムの両方が含まれます。

コンテナファイルシステムは、/ proc / $ pid/rootリンクを介してポッド内の他のコンテナに表示されます。

https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/#understanding -process-namespace-sharing

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleを使用して、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /closeを使用して解決してください。

sig-testing、kubernetes / test-infra、 fejtaにフィードバックを送信します。
/ lifecycle stale

/ remove-lifecycle stale

kubectl alpha debug -it ephemeral-demo --image =busybox --target = ephemeral-demo

error: ephemeral containers are disabled for this cluster

@whereisaaronほとんどのクラウドプロバイダーはこれをサポートしていないようです。オンプレミスでは、ノードに移動してdocker execをコンテナーに入れることができます。 繰り返しになりますが、有用性はかなり限られているようです。

また、 /proc/$pid/rootを介したアクセスは、私が望むものではありません。「サイドウィンドウ」を介さずに直接アクセスしたいと思います。 たとえば、ルートファイルシステムが期待する場所にない場合、_continer_でapt/apkのようなutilsを実行するのは簡単ではありません。

同様の問題がありました。公式のヘルムチャート（jenkins）によってデプロイされた公式のイメージに、いくつかのディレクトリ、リンクを作成し、root以外のユーザーのアクセス許可を追加する必要がありました。

exec-asプラグインを使用して解決することができました。

計画されたDockerの非推奨とその後の削除で、これはいつ対処されますか？ エフェメラルコンテナはまだアルファ版です。 DockerをCRIとして使用しない安定した代替手段は何ですか？

アルファ版であることに加えて、エフェメラルコンテナは、単純なkubectl exec --userよりもはるかに複雑に使用できます。

これのもう1つのユースケースは、コンテナーでスクリプトを手動で実行することです。 たとえば、NextCloudのoccメンテナンススクリプトはwww-dataとして実行する必要があります。 イメージにはsudoなどはありません。ドキュメントでは、Docker環境でdocker exec -u 33を使用することをお勧めします。

あなたは実行することによってnextcloudの問題を解決することができます

su -s /bin/bash www-data

しかし、これは理想的ではありません。