Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

SecretClass access control

オープン
#613 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
kubernetes
領域
authorization, security

調査の方向性

Kubernetes の admission control 拡張ポイントと、リンクされている OPA Kubernetes ドキュメントから始めます。プロジェクトが SecretClass のネイティブなアクセス制御を提供すべきか、それとも admission-hook アプローチを文書化すべきかを明確にし、対象 Namespaces の allowlist がどのように機能するかを定義します。選択したアプローチとその範囲が明示的に指定されていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

We should have a way to control who's allowed to mount which SecretClass.

It's not really practical to control based on the deploying user, because the idea of a "source user" in the first place is about as clear as mud in K8s (the end user creating the StatefulSet? The controller creating the Pod from that? The controller creating the PersistentVolumeClaim from that? The controller creating the PersistentVolume from that?).

The best we could do would probably be to allowlist individual target Namespaces.

This is theoretically already possible via a K8s admission hook like OPA; we should either implement something native or document how to accomplish it using one of those.

主要言語
Rust
スター
13
フォーク
8
平均マージ
1日 8時間
マージ済み PR（30日）
10

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

stackabletech/secret-operator のほかの issue

stackabletech/secret-operator の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。