stackabletech / stackabletech/opa-operator

Enable client authentication and authorization

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

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

主要言語
Rust
スター
21
フォーク
5
平均マージ
12時間 44分
マージ済み PR(30日)
11

説明

Description

As a user of OpenPolicyAgent (OPA) I want to be sure that only authenticated & authorized clients can get data (which might include PII data from UserInfoFetcher and other sources).

OPA supports Bearer tokens and Client TLS certificates. The latter fits better into our platform so it's the preferred way but the bearer token can be used as well if there are any hurdles towards implementing client certificates.

Value

We want the SDP platform to be as secure as possible by default and design and in addition this will be a requirement of the Cyber Resilience Act we'll have to fulfill.

Therefore, we need to authenticate and authorize any client requests coming to OPA.

Dependencies

This requires the Secret Operator (I assume) to provide the necessary client certificates for all clients (i.e. authorizers) to be able to authenticate against OPA.

Tasks

- [ ] Change OPA Operator to set the required settings for authentication
- [ ] Create default authorization rule in OPA
- [ ] Change authorizers to use client certificates to authenticate themselves against OPA
- [ ] Change operators to provision the necessary client certificates
- [ ] Update demos and integration tests to use this functionality
- [ ] Document that authentication is now used for OPA

Acceptance Criteria

  • OPA does not accept unauthenticated requests anymore
  • All authorizers authenticate themselves when speaking to OPA

(Information Security) Risk Assessment

This will strictly make our product more secure and helps us with regulations such as the Cyber Resilience Act.
Additional risks are the need to create TLS certificates and protect them but that is already part of the platform.

Release Notes

All authorizers speaking to OpenPolicyAgent (OPA) now use Client TLS certificates to authenticate themselves against OPA.

Remarks

Be aware of this section in the docs:

Note that TLS authentication does not disable non-HTTPS listeners. To ensure that all your communication is secured, it should be paired with an authorization policy (see below) that at least requires the client identity (input.identity) to be set.

In general please read the docs on this feature before starting any implementation.

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

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

はじめの一歩

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

調査の方向性

リンクされた OPA セキュリティドキュメントから始め、次にタスクリストに記載されている OPA Operator、authorizers、operators、demos、integration tests を確認します。未認証のリクエストが拒否され、authorizers がクライアント証明書を使用し、ドキュメント化された demos と tests が新しい認証フローをカバーしていれば完了です。

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

評価

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

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

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