アドミッションコントローラーコードは、 https ：//github.com/kubernetes/kubernetes/pull/24600で確認中です。

この機能は、OpenShiftで最初に公開されたため、ベータ版に直接スキップされます。

kubernetes / kubernetes＃24600ではデフォルトで無効になっています。 その後、PSPをユーザーにリンクするためにアドミッションコントローラーを変更する必要があります。

PSP（サブジェクトレベルのアクセス）の次のステップの依存関係としてhttps://github.com/kubernetes/kubernetes/pull/20573に注意してください

これの状況はどうですか？ 最初のコメントの説明は最新ですか？

最初のコメントの説明は最新ですか

いいえ（更新する権限がありません）。 アルファ要件はすべて満たされていると思います。 初期タイプ、API、およびテストがマージされました。 アドミッションコントローラはデフォルトでは有効になっていません。

IMOベータ/1.4の残りの作業は、権限の認証統合、制約する新しいフィールドの更新（seccomp-進行中、sysctl）、および必要なドキュメント/チュートリアルです。

そしてe2eテスト。

2016年7月12日火曜日の午前6時23分、 PaulWeilnotifications @ github.comは次のように書いています。

最初のコメントの説明は最新ですか

いいえ（更新する権限がありません）。 私はすべてのアルファを信じています
要件が満たされています。 初期のタイプ、API、およびテストは
マージされました。 アドミッションコントローラはデフォルトでは有効になっていません。

IMOベータ/1.4の残りの作業は、権限の認証統合です。
制約したい新しいフィールドの更新（seccomp-進行中、
sysctl）、および必要なドキュメント/チュートリアル。

—
スレッドを作成したため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/features/issues/5#issuecomment -232045429、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe/AHuudqFwephlYk0Y1PS77y0xxA5QW0_-ks5qU5U7gaJpZM4IaU8n
。

クラウドプロバイダーとのやり取りはどうですか？ 各ポッドに異なるIAMロールを簡単に割り当てて、実際に必要なクラウドサービスのサブセットにのみアクセスできるようにすると便利です。 範囲内にあるのでしょうか、それともSecurityContextの詳細と見なされるのでしょうか。

@thercは、ServiceAccountを介して実行する必要があります。

@goltermannこれがアルファでマークされていることに気づきましたが、おそらくhttps://github.com/kubernetes/features/issues/5#issuecomment-217939650に基づくベータタグが必要だと思います

@erictuneは@ pweil-コメントに基づいて正しく聞こえますか？

@goltermann技術的には、これは1.3ではベータ版だったと思います。開発は進行中ですが、1.4では新しいものではありません。

はい、ベータ版は正しいです。 今日初めにアルファと言ったとき、私は間違っていました。

素晴らしい、それを修正しました

@ pweil-ドキュメントの準備はできていますか？ ドキュメントをhttps://github.com/kubernetes/kubernetes.github.ioに更新してから、PR番号を追加し、問題の説明で[ドキュメント]チェックボックスをオンにしてください

@janetkuo docs PR https://github.com/kubernetes/kubernetes.github.io/pull/1150

編集： https ：//github.com/kubernetes/kubernetes.github.io/pull/1206は正しい1.4PRです

cc @ kubernetes / feature-reviewers

@ pweil-このPRは実際のものだと思います-https ：//github.com/kubernetes/kubernetes.github.io/pull/1206？

正しい

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

/lifecycle frozenコメントを使用して、問題が自動終了しないようにします。

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

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

1.10では、PSPを非拡張APIグループに移動する作業が行われています。
cc @ php-coder

@erictuneドキュメントの更新をお願いします。 [1.10機能追跡スプレッドシート[（https://docs.google.com/spreadsheets/d/17bZrKTk8dOx5nomLrD1-93uBfajK5JS-v1o-nCLJmzE/edit#gid=0））も参照してください。 ご不明な点がございましたらlmk。 ドキュメントPRをレビューし、3/9までにマージする必要があります。 ありがとう！

@ php-coder ^

@ Bradamant3 @liggittどのようなドキュメントの更新が必要ですか？

APIグループの移行に関連する変更については、 https ： //github.com/kubernetes/website/pull/7562、https ：//github.com/kubernetes/examples/pull/206、https ：/を送信しました。

私はPSPドキュメントの更新の適切な所有者ではありません。

2018年3月2日金曜日午前11時26分、Vyacheslav Semushin <
[email protected]>は次のように書いています：

@ Bradamant3 https://github.com/bradamant3 @liggitt
https://github.com/liggittどのようなドキュメントの更新が必要ですか？

APIグループの移行に関連する変更について、私は以下を提出しました。
kubernetes / website＃7562 https://github.com/kubernetes/website/pull/7562 、
kubernetes / examples＃206 https://github.com/kubernetes/examples/pull/206 、
およびkubernetes / examples＃208
https://github.com/kubernetes/examples/pull/208

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

必要なのはそれだけです。 追跡スプレッドシートにPRを追加しました。 ありがとう！

@ php-coder @liggitt @tallclair
1.11でこれについて何か計画はありますか？

もしそうなら、あなたはその機能が適切なもので最新であることを確認してください：

• 説明
• マイルストーン
• 譲受人
• ラベル：
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

@ php-coder @justaugustusのコメントに、ここで行っている作業で返信できますか？ ポリシーグループの移動以外に変更はありますか？

ポリシーグループの移動以外に変更はありますか？

いいえ、私はこれだけに取り組みました。

@liggittが時間があるときに説明を更新することを願っています（適切な権限がないため）。

終わり。

@tallclair明確にするために、1.11のターゲットとして安定して追跡していますよね？
ラベルを更新しましたが、確認したいだけです。

いいえ、これはまだベータ版です。 PodSecurityPolicyが安定するかどうかはわかりませんが（つまり、他の何かに取って代わられる）、他の人はこれについて私に同意しないかもしれません。

とった。 更新してくれてありがとう、@ tallclair！

@justaugustus現在のリリースでは大きな進展はないため、これを1.11マイルストーンから削除します。

1.12のアップデートは予定されていません

@ tallclair1.12でRunAsGroupPSPノブを入手できるかもしれません

確認します。 ただし、これはまだベータ版です。 現時点では、PSPがGAに移行する予定はありません。 これを進める前に対処する必要のあるいくつかの主要なユーザビリティの問題があります。 （https://github.com/kubernetes/kubernetes/issues/60001およびhttps://github.com/kubernetes/kubernetes/issues/56174を参照）

/ unassign

/ assign @tallclair

こんにちは
この拡張機能は以前に追跡されているため、チェックインして、Kubernetes1.13のステージを卒業する計画があるかどうかを確認したいと思います。 このリリースは、より「安定した」ものを目標としており、積極的なタイムラインがあります。 次の期限に間に合うと確信できる場合にのみ、この拡張機能を含めてください。

• ドキュメント（オープンプレースホルダーPR）：11/8
• コードスラッシュ：11/9
• コードフリーズの開始：11/15
• ドキュメントの完成とレビュー：11/27

1.13拡張機能追跡シートに含める必要がある場合は、将来の追跡とping @ kacole2のために元の投稿のマイルストーンを更新してください。

ありがとう！

1.13では変更は予定されていません。

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

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

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

/ remove-lifecycle stale

@tallclairこんにちは-私は1.14の拡張機能のリーダーであり、この問題をチェックして、1.14リリースで計画されている作業（ある場合）を確認しています。 拡張機能のフリーズは1月29日であり、すべての拡張機能にはKEPが必要であることを思い出してください。

1.14には何も計画されていません。

これがGAになるためのギャップは何ですか？ 少ししか考えられませんが、説明に基準がありません。

これをGAに移行する前に、次の問題を修正する必要があります。

1. 欠陥のある認証モデル-PSPの使用はRBACを介して付与され、ユーザーまたは作成されたポッドのいずれかに付与できます。 ユーザーにそれを付与することは直感的なアプローチですが、問題があります（説明を参照）。 このアプローチには、セキュリティ上の問題もいくつかあります。
2. 展開が難しい-ポッドはデフォルトで拒否されるため、PSPを壊さずにすべてのクラスターに展開することはできません。 同様に、PSPを有効にしたいユーザーは、PSPを有効にする前に、すべてのワークロードを完全にカバーする必要があります。これにより、PSPを有効にすることが困難になります（したがって、使用量が比較的少なくなります）。 機能を明示的に有効にする必要があるため、十分なテストカバレッジがありません（機能マトリックスが複雑すぎます）。
3. 一貫性のないAPI-基本的な問題は少ないですが、k8sリリースの長いスパンにわたるPSP APIの進化により、多くの不整合が発生し、使用が困難になっています。 特に、ミューテーションは検証と一緒にまとめられます。これにより、ポッドが複数のPSPにアクセスできる場合に予期しない結果が生じる可能性があります。

@liggittと私はこれに対処する方法についていくつかのアイデアを持っていますが、これがコアKubernetesに属するかどうかについては未解決の質問があります。 GAに移行する計画か、非推奨の計画のいずれかで、来月にロードマップを公開したいと思います。

情報を共有していただきありがとうございます！

ポッドはデフォルトで拒否されるため、PSPをすべてのクラスターにロールアウトするにはそれらを壊さないでください。

そうではないと思います。 これを行うには、最初に十分に開いている（またはすべて開いている）PodSecurityPolicyを作成し、次にそれを徐々に改良します。

@ zhouhaibing089 Kubrenetesユーザーは、ポリシーを制御するために機能するその方法を使用できます。 ただし、PodSecurityPolicyはクラスターを開くだけなので、Kubernetesのデフォルトとしてロールアウトすることはできません。つまり、システム制御のallow-allPSPを管理することは非常に困難です。

こんにちは@ liggitt @ tallclair 、私は1.15のエンハンスメントリードです。 この機能は1.15でアルファ/ベータ/安定ステージを卒業する予定ですか？ 適切に追跡してスプレッドシートに追加できるように、お知らせください。 コミュニティの提案は、1.15に含めるためにKEPに移行する必要があります。

コーディングを開始したら、適切に追跡できるように、この号に関連するすべてのk / kPRをリストしてください。

1.15の変更は予定されていません

@ tallclair1.16でこの土地をGAとして見たいと思います。 それは可能ですか？

@ lachie83いいえ、PodSecurityPolicyをGAに移行するかどうかはわかりません。 これがKubernetesコアによって解決されるべきユースケースであるかどうかは明らかではなく、コア外の代替案を検討しています。 詳細については、SIG-Authにとって良いトピックです。

@tallclair Open Policy Agentのゲートキーパーのようなものは、頭を下げるためのより良い道でしょうか？

はい、正確に。 それが主要な候補である可能性があります。私はそのチームと緊密に協力して、これらのユースケースを確実にカバーできるようにしています。

私が待ち望んでいたことの1つは、 PodSecurityPolicy -> OPAレゴポリシーを変換できる可能性のあるツールです。 それはあなたの観点からそれらを非難することをはるかに簡単にするでしょう。

@tallclairは迅速な対応に感謝します

@SEJeffは同意しました。 機能のパリティと移行パスが明確に置き換えられるまで、PodSecurityPolicyは廃止されません。

ねえ@tallclair 、あなたはGAへのロードマップまたは非推奨の計画について言及しました。 後者に傾いているようです。

解決策としてPSPを検討している人々がループを閉じるのを助けるために、何か書かれたものがありますか？

まだ。 躊躇の一部は、明確な代替品が見つかるまで、他の何かを優先して非推奨にすることを言いたくないということです。 私はゲートキーパーに興奮していますが、PSPを置き換えるために必要な機能（または安定性）がまだありません。 もう1つの可能性は、PSPをツリーの外に移動し、それをアドミッションWebhookとしてGAに持ってくることです（2つのオプションは相互に排他的ではありません）。 ただし、ロードマップはまだ正式に策定されていません。

Wtf

こんにちは@tallclairは、1.16でもここでは何も起きていないようですので、同じままにしておきます。

こんにちは@ tallclair -1.17エンハンスメントリードはここにあります-これは1.17の場合と同じように見えます。 それが変わった場合は、遠慮なく私に突いてください。追跡シートに追加できます👍

PSPの将来への明確な道についてこれ以上の議論はありましたか？

はい、正確に。 それが主要な候補である可能性があります。私はそのチームと緊密に協力して、これらのユースケースを確実にカバーできるようにしています。

@ tallclair-ほとんどのPSPチェックをKyvernoに実装しました。 あなたは見てみるのを手伝ってもらえますか？ アイデアや詳細について話し合いたいと思います。

https://github.com/nirmata/kyverno/blob/master/samples/README.md

ゲートキーパープロジェクトは、PSP後の世界がどのようになるかについても検討しています。 私たちの最初のアプローチは、PSPリソースを個々の制約に分割することでした。 私たちは、このアプローチに対するコミュニティの考えが何であるか疑問に思いました。 たぶん、これらのポリシーがどのように構成されているかを再考するのに良い時期でしょうか？ 新規ユーザーと既存のPSPユーザーの両方の移行も重要になります。

cc @maxsmythe @sozercan @tsandall

ポリシーを個々の制約に分割すること、つまり、さらに多くの制約オブジェクトを作成する必要があることについて、いくつかの懸念があります。 異なるワークロード用にそれらを複製または変更する必要があると思う場合、それが非常に複雑になるのではないかと心配しています。

最善のアプローチはユーザー中心のアプローチだと思います。 PSPがどのように使用されているかについて実際のフィードバックを取得し、これらの代替プラグインの下で同様のセットアップがどのように見えるかを確認できれば、それは設計の形成に役立ちます。

@tallclair私たちが追求しているユースケースの1つは、名前空間ベースのマルチテナンシーに関連しています。 ポリシーを使用して制限を適用し、名前空間が適切に構成されていることを確認することを目的としています。

これをGAに移行する前に、次の問題を修正する必要があります。

1. 欠陥のある認証モデル-PSPの使用はRBACを介して付与され、ユーザーまたは作成されたポッドのいずれかに付与できます。 ユーザーにそれを付与することは直感的なアプローチですが、問題があります（説明を参照）。 このアプローチには、セキュリティ上の問題もいくつかあります。

@tallclair 、私は上記について疑問に思っています-このアプローチがどのように問題があるか、および/またはセキュリティの問題があるかについて詳しく説明できますか？

誰かがもっと情報を得て、このツイートを確認してください：

https://twitter.com/TechJournalist/status/1197658440040165377

そしてそれが本当なら、今日のLinux機能を制限するためにPSPを使用している人々は今後何をすべきでしょうか？

こんにちは、みんな、
これは非常に興味深い議論であり、現在、Kubernetesクラスターでポッドの作成を保護するためのソリューションを探しています。

OPAゲートキーパーとPodSecurityPoliciesの両方、およびOPA制約でPSPを再実装するための取り組みを確認しました。
この比較でわかった基本的な問題は、2つの反対のモデルを扱っていることです。

• OPAゲートキーパーは、デフォルトで開くモデルに従います。このモデルでは、すべてが許可され、管理者は制約のある特定のものを禁止します。
• PSPは、すべてが禁止され、管理者がポリシーで特定のことを許可する、デフォルトで閉じられたモデルに従います。

セキュリティの観点からは、すべてのワークロードがそれに準拠する必要があるため、既存のクラスターに組み込むのはより困難ですが、PSPモデルの方が優れていると私は主張します。

PSPと制約フレームワークの間のアーキテクチャにおけるこの基本的なギャップをどのように埋める予定ですか？

/ cc @ritazh PSP機能のOPAへの移植に取り組んできたので、これについてのご意見をお聞かせください。

さまざまなアプローチにより、移行は確実に複雑になります。 移行をスムーズにするためのさまざまな方法を模索しています。

完璧な世界では、デフォルトですべて拒否する方がより安全なアプローチであることに同意します。 しかし、それがPSPの使用と展開を非常に難しくしている理由の1つです。 実際には、許可を徐々に下げる方が実現可能だと思います。古い格言が進むにつれて、「最高のセキュリティは使用するセキュリティです」。

ちなみに、制約の例外をオプトアウト/除外/取得する方法についても説明しています（たとえば、kube-system名前空間を保護するため）。 これがどのように機能するかに応じて、すべてをロックダウンしてから例外を許可することにより、デフォルトで拒否するアプローチを実装できます。 それが私たちが設計したいユースケースであるかどうかはわかりませんが...

@tallclair 1.18でこれが進展すると思いますか？ 私はリリースの拡張シャドウであり、これを追跡する必要があるかどうかを知りたいです。

1.18の変更は予定されていません

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

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

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

/ remove-lifecycle stale

@tallclairこんにちはティム。 1.19でこれについて何か計画はありますか？

v1.19の計画はありませんが、v1.20の時間枠で何らかの動きが見られることを期待しています。

Open PolicyAgentを使用したKubernetesポッドセキュリティポリシーに遭遇しました。 @tallclairは、私たちを妨げているものと、助けが必要な場所を共有できます。また、喜んで貢献してください。

私たちをブロックしているものを共有できますか

基本的に、私たちは前進する道を決定する必要があります。 現在、PSPは現在の形でGAに移行すべきではないという合意があると思いますが、まだ代替品を決定していません。 私たちが議論したオプション：

1. 代替品はありません-アドミッションWebhookを備えたサードパーティのオプションから選択することをお勧めします。 最近公開されたポッドセキュリティ標準ドキュメントは、同等の機能を促進することにより、これをよりスムーズにしようとしています。
2. 代替の組み込みコントロール
   
   
   
   1. @ deads2kは、アップストリームのopenshiftsSecurityContextConstraintsを提案しました
   
   
   2. 上記でリンクされている標準ポリシーのみを適用する最小限の構成可能な機能を提案しました（さらに構成可能性が必要な場合は、サードパーティのソリューションをお勧めします）
   
   
3. ポッドのセキュリティポリシーを修正する-いくつかの問題は設計にとって十分に重要ですが、これは下位互換性がない必要があり、その時点で（2）の新しい代替手段になる可能性があります。

https://github.com/kubernetes/kubernetes/pull/90603を正しく読んでいますか？ポッドセキュリティ標準が公開されているため、APIサーバーでPSPの代替が計画されておらず、代替を外部システムとして実装する必要がありますか？

https://github.com/kubernetes/enhancements/issues/5#issuecomment-637066475を参照してください

1.22の現在のベータバージョンの非推奨スケジュールは、標準のポッドセキュリティプロファイルのツリー内実装が提供されるかどうかとは無関係です。 それはまだ決定されていません。

ありがとう@liggittは何も設定されていないことを確認していました。 もともと、代替品が利用可能になるまで、廃止されるものは何もないと考えていました。 何らかの形で決定が下されたかどうかは明確ではありませんでした。

非推奨のタイムラインはPSPに固有のものではなく、 https：//github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabetaの一部として追加されました。

私がこれを正しく読んでいる場合、非推奨を推進しているのは、9か月以上同じベータバージョンのAPIがないため、PSPを昇格または非推奨にする必要があり、pspの新しいベータまたはGAがないためです。交換が決定されていなくても、非推奨に向けて軌道に乗る必要がありますか？

私がこれを正しく読んでいる場合、非推奨を推進しているのは、9か月以上同じベータバージョンのAPIを使用してはならないということです

まさに。 すべての組み込みAPIの将来のすべてのベータ版には、最初に導入されたときに、事前に焼き付けられた非推奨および削除のターゲットが付属します。

こんにちは@tallclair

拡張機能はここをリードします。 1.20でこれについて何か計画はありますか？

ありがとう、
キルステン

v1.20の計画はありません。

この状況は、高度なセキュリティクラスターを実行する必要がある私たちにとって非常に苛立たしいものです。 私たちのオプションは次のとおりです。

1. 座って、PSPが非推奨になるのを待ちます。
2. OPAはRegoで完全に制限されたPSPの置き換えを実行する方法を文書化していないため、ワークロードのランタイムセキュリティの実施をベンダー（Styra）にアウトソーシングします。

そのため、私の会社は完全にロックダウンされたPSPを実装しました。 それらは実装が簡単ではなく、デバッグは面倒ですが、非常に機能的であり、実際に機能します。 このように使用する方法と、例外が発生した場合の処理​​方法について詳しく説明したブログ投稿も公開しました。

IMO、PSPベータはそのままメインラインのkubernetesコアにマージする必要があります。 私の理由は次のとおりです。

1. PSPには欠陥がありますが、機能し、10リリース間機能しています。
2. プロジェクトとしてのKubernetesは、ワークロードのランタイムセキュリティに注意を払う必要があります。 コンテナの脱出は簡単すぎます。 PSPは、攻撃者にとってこれを困難にする数少ないツールの1つです。
3. パーフェクトは完了の敵です。 PSPをそのままマージし、「より優れた」実装をpolicy / v2にプッシュします。
4. 最後に、そして最も重要なことは、OSS開発者が、Styraのようなベンダーに余裕のある企業だけでなく、より高度なセキュリティクラスターを実行できるようにすることです。

@ zapman449 「完全に制限されたPSPの交換」とはどういう意味かを明確にできますか？

うまくいけば、 Gatekeeper PSPライブラリによって、PSPで使用されるものと同様のルールを簡単に適用できるようになります。 私はあなたが見ている機能的なギャップに間違いなく興味があります。

@ zapman449あなたはたまたまそのブログ投稿へのリンクを持っていますか？

@christianhuening https://developer.squareup.com/blog/kubernetes-pod-security-policies

@maxsmythe私はGatekeeperPSPが何をしているかについて追いついていないので、レビューします。

しかし、私が意味するのは：

1. NET_BIND_SERVICE、SYS_ADMINなどのプロセス機能を完全に制御
2. UID / GID / FSGroupsをゼロ以外の値に制限します
3. マウント可能なホストパスの明示的なリスト
4. 許可されるボリュームマウントのタイプの明示的なリスト
5. 特権のブロック、特権の昇格のブロック
6. ホストレベルのプロセス間通信プリミティブへのアクセスをブロックする
7. ホストネットワークへのアクセスをブロックする
8. 許可されるホストポートを制限する
9. readOnlyRootFilesystemを適用します
10. SELinuxの接続ポイント

これらは現在、PSPとともに提供されています。

ウィッシュリストをお求めの場合は、次のようにお願いします。

1. コンテナからのSysCallのスマートなデフォルト。 ほとんどのコンテナが必要とするLinuxシステムコールリスト全体のわずかな割合があります。 ほとんどのコンテナをそのリストに制限してから、特定のサービスアカウントが所有する特定のポッドに対する特定の呼び出しを明示的に許可するか、特定のサービスアカウントにカルテブランシュを許可します。
2. もう少し夢を見て、何かを思いつきます。 ;-)

@ zapman449-まだご覧になっていない場合は、前回のsig-authミーティングでPSPの将来について話し合いました（https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#heading=h.hsgtsqg83z5u ）。 可能であれば12月9日の会議でも議論を続けますが、メーリングリストに提案が送られない限り、最終的な決定を下すことはありません。

ここでの私たちの意図は、誰もが高くて乾燥したままにしないことです。 PSPがKubernetesの重要なセキュリティニーズに対応していることはわかっています。これらのディスカッションの目的は、将来これらのニーズを満たすための最善の方法を見つけることです。