やはりポリシー...！ポリシーは全てを解決する...！OPA で始める Policy as Code

© 2023, Amazon Web Services, Inc. or its affiliates. All
rights reserved. D E V D AY J U N 2 2 / 2 0 2 3

rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. 「やはりポリシー…!! ポリシーは全てを解決する…!! 」 OPA で始める Policy as Code Hiroto Sakuraya B - 3 Partner Solutions Architect Amazon Web Services Japan G.K.

rights reserved. ⾃⼰紹介名前︓櫻⾕広⼈ (Hiroto Sakuraya) 所属︓AWS Technology Partnerships SaaS, Partner Solutions Architect 経歴︓主にバックエンドエンジニアとして Web サービスやネイティブアプリの開発に従事。前職では CtoC のスタートアップで執⾏役員 CTO を務める。好きな AWS サービス︓Amazon EventBridge 3

rights reserved. • 本セッションでは、AWS のサービスだけでなく、OSS のソフトウェアについても取り扱います。内容については⼗分注意して資料を作成していますが、実際の動作や仕様に差異がある場合は、公式ドキュメントをご参照ください • 2023 年 6 ⽉ 19 ⽇時点の情報となります。利⽤の際は、併せて公式ドキュメントから最新の情報をご確認ください。はじめに

rights reserved. • Policy as Code って何だろう • 認可処理、もっとスマートに書けないかなあ • 各技術スタックによって⽅法も違うし • テストとか⼤変なんだよなあ • 開発の⽣産性も落としたくないし • 何かいい⽅法はないものかこんなことについて考えていくセッションです

rights reserved. • Policy as Code とは • アクセスコントロールについて • OPA (Open Policy Agent) の紹介 • AWS における PBAC の実装⽅法 • まとめアジェンダ

rights reserved. Policy as Code 本セッションのテーマ

rights reserved. ポリシー (Policy) とは • 組織や政治における政策、⽅針、規定 • 個⼈の信条や信念 IT の世界では、特定の要件や、それを実装する設定などを指した⾔葉としてよく使われる例︓セキュリティポリシーパスワードポリシー認可ポリシールーティングポリシー⼀般的な定義において

rights reserved. 我々は⽇々どんなポリシーを運⽤しているのか︖ o 開発者は本番リソースにアクセスできない o 社内のネットワークからのみ SSH で接続できる o 脆弱性が含まれるコンテナイメージはデプロイしない o 管理者のみがこのページを閲覧できる etc.

rights reserved. ポリシー (Policy) をもう少し掘り下げてみる • 何らかのルールが明⽂化されたもの • 定義されたルールは、それが守られるように運⽤する必要があるここでの課題は Ø どのような形式でルールを記述するか︖ Ø 定義したルールをどのように適⽤/強制するか︖ Ø 変更などのライフサイクルをどのように管理するか︖ 汎⽤的な⽅法で実現できると開発者が覚えることも少なくて済むし⼤規模でもスケールしそう...🤔

rights reserved. それぞれの実現⽅法は結構バラバラ... o 開発者は本番リソースにアクセスできない ex. AWS IAM、IAM ポリシー、リソースタグ o 社内のネットワークからのみ SSH で接続できる ex. セキュリティグループ、ファイアウォール、sshd_config o 脆弱性が含まれるコンテナイメージはデプロイしない ex. Trivy, Amazon ECR イメージスキャン, AWS CodePipeline o 管理者のみがこのページを閲覧できる ex. アプリケーション内でロジックを独⾃実装 etc. 例︓AWS 上に構築するシステムの場合

rights reserved. 適切にポリシーを運⽤するための 3 つの柱ポリシーの記述ポリシーの管理ポリシーの適⽤

rights reserved. Policy as Code 本セッションのテーマ

rights reserved. コードでポリシーを記述/運⽤するとポリシーの記述ポリシーの管理ポリシーの適⽤ o 開発者にとって理解しやすい o 決定論的で⾃明なルール o 様々な構⽂を使った複雑な定義 o 慣れたツールが利⽤できる o バージョン管理 o 容易なテスト o 再利⽤性 o アプリケーションとの統合が容易 o 独⽴した技術スタックとして運⽤できる

rights reserved. ユーザーアプリケーションデータベースコードで記述すると⾔っても... if ( resource.readOnly == false && (user.role == "admin" || (user.role == "operator" && user.dept == "finance") || (user.role == "developer" && resource.env != "prod") ) ) { # allow # do something } else { # deny # return error message } アプリケーションから適切に分離し、⼤規模なシステムでもスケールするような実装が必要 Ø どのような形式でルールを記述するか︖ Ø 定義したルールをどのように適⽤/強制するか︖ Ø 変更などのライフサイクルをどのように管理するか︖ 先ほどの課題は解決できるか...︖

rights reserved. ⼀般的な定義︓Policy as Code とは Policy as Code とは、⾼級⾔語を⽤いて書かれたコードによって、ポリシーを管理および⾃動化するという考え⽅である。テキストファイルにコードとしてポリシーを表現することによって、バージョン管理や⾃動化テスト、⾃動デプロイのような実績のあるソフトウェア開発のベストプラクティスを適⽤することができる。 by HashiCorp ” ” Policy as Code とは、コードを使ってポリシーを定義、更新、共有、適⽤するようなポリシー管理の試みである。⼿動プロセスの代わりにコードベースの⾃動化を活⽤してポリシーを管理することで、チームは迅速に動くことができ。またヒューマンエラーによるミスの可能性を減らすことができる。 by Palo Alto Networks ” ” * 原⽂ (英語) を私が訳したものです

rights reserved. （再掲）どんなポリシーを運⽤しているか︖ o 開発者は本番リソースにアクセスできない o 社内のネットワークからのみ SSH で接続できる o 脆弱性が含まれるコンテナイメージはデプロイしない o 管理者のみがこのページを閲覧できる

rights reserved. （再掲）どんなポリシーを運⽤しているか︖ o 開発者は本番リソースにアクセスできない o 社内のネットワークからのみ SSH で接続できる o 脆弱性が含まれるコンテナイメージはデプロイしない o 管理者のみがこのページを閲覧できるこれらのポリシーはアクセスコントロールと関連している

rights reserved. アクセスコントロールにおけるポリシー • 誰に何を許可/拒否するか o 細かで柔軟な制御 (Fine-Grained Access Control) o リアルタイムな評価、スケーラビリティ o アプリケーション開発の⽣産性 o コンプライアンス要件への準拠 o 複数のドメインにまたがる汎⽤性、再利⽤性アクセスコントロールに求められる要件

rights reserved. AWS における（これまでの）アクセスコントロールの実装パターン RBAC (Role-based) ABAC (Attribute-based)

rights reserved. Role-based Access Control (RBAC) Users Permissions Resources (≒ Policy)

rights reserved. Attribute-based Access Control (ABAC) Users Permissions Resources { "Role": "Dev", "Project": "ABC", "CostCenter": 123 } { "Project": "ABC" }

rights reserved. RBAC と ABAC の特徴 RBAC ABAC o アイデンティティをベースに権限を付与するやり⽅ o 直感的で分かりやすく、始めやすい o 必要な権限をうまく整理・グループ化することで効率的な管理を実現 o 属性情報をベースに権限を付与するやり⽅ o リソースが増えても修正は不要で、⼤規模でもスケールする o 属性をうまく活⽤することで必要なポリシーの数を削減可能 * RBAC とABAC を併⽤する選択肢も

rights reserved. ここまでのまとめ o IT の世界では⾄る所で様々な形でポリシーが運⽤されている ex. API の認可、ホスト管理、ネットワーク制御、 Kubernetes マニフェスト・IaC テンプレートなどのレビュークラウドにおける開発者の権限管理、etc. o ポリシーの実装⽅法はドメインによってバラバラ o 効率的な開発/運⽤を⾏うには、適切なポリシーの記述/管理/適⽤⽅法を考える必要がある Policy as Code または OPA の導⼊はこれらの課題に対する解となり得るか︖︖

rights reserved. Open Policy Agent (OPA) o オープンソースの汎⽤ポリシーエンジン o CNCF graduated project *1 o domain-agnostic Ø 特定のドメインに依存せずに利⽤可能 Ø 例︓Kubernetes, Envoy, Terraform, AWS, Linux, SQL, GraphQL API etc. o 構造化データを⼊⼒ (input) として受け取り、ポリシーを評価 (evaluate) して、判定結果 (decision) を返す o ポリシーは Rego という宣⾔型⾔語で記述する *1 Cloud Native Computing Foundation

rights reserved. Rego のサンプルコード Demo

rights reserved. OPA は何を⽬指しているのか︖ 1. クラウドネイティブ環境におけるポリシー⾔語/モデル/API の統⼀ (汎⽤的なツールセット、フレームワークとしての OPA) 2. サービスコードから認可処理を分離することによる開発⽣産性、パフォーマンス、可⽤性の向上 Source: https://www.openpolicyagent.org/

rights reserved. 基本的な OPA の仕組み Service OPA Request, Event, etc. Query (any JSON value) Decision (any JSON value) Policy (Rego) Data (JSON) OPA は、ポリシーに基づく評価のみを⾏う何かに対してポリシーの強制は⾏うことはない評価を踏まえてどのようなアクションを取るかは結果を受け取る側次第⼊⼒および出⼒のフォーマットは JSON シンプルな allow/deny, true/false 以外にも任意の構造化データを返すことができる

rights reserved. OPA の主な利⽤⽅法デーモンサイドカー (GateKeeper) Go ライブラリその他に CLI, SDK, WebAssemly なども HTTP しゃべれるよ︕ Go で書かれてるよ︕ HTTP しゃべれるよ︕

rights reserved. 1. Kubernetes OPA (GateKeeper) API Request kubectl apply ~ Admission request Admission response (allow/deny) • Kubernetes の Admission Controller として OPA を利⽤することができる • Pod Security Policy (PSP) に代わるツール • リソースの spec に⼀定の制約を課すなどのユースケースに活⽤できる Ø 承認済みのリポジトリのイメージのみ利⽤可能 Ø すべての Pod に resource limit の設定を必須化 Ø すべての Ingress のホスト名を⼀意に Ø すべての Namespace に特定のラベルの設定を必須化 • GateKeeper としてデプロイすることでポリシーを Kubernetes ネイティブな CRD として管理できる

rights reserved. サンプルポリシー package kubernetes.admission deny[msg] { input.request.kind.kind == "Pod" image := input.request.object.spec.containers[_].image not startswith(image, "hooli.com/") msg := sprintf("image '%v' comes from untrusted registry", [image]) } kind: Pod apiVersion: v1 metadata: name: myapp spec: containers: - image: nginx name: nginx-frontend - image: mysql name: mysql-backend { "deny": [ "image 'mysql' comes from untrusted registry", "image 'nginx' comes from untrusted registry" ] } policy input output 例︓信頼されていないレジストリ (hooli.com/ 以外) のイメージを参照する Pod の起動を禁⽌するポリシー左記のマニフェストを apply すると Kubernetes API の実⾏は失敗し、下記のメッセージを返す

rights reserved. 2. Envoy OPA request Envoy proxy • External Authorization フィルタを利⽤して認可処理を OPA に委譲することができる • OPA-Envoy プラグインをサイドカーとしてデプロイ • Envoy proxy と OPA 間は gRPC で通信 • ポリシーは ConfigMap で管理することもできるが、商⽤環境ではリモートサーバーから Bundles として定期的にダウンロードする⽅法を推奨 External AuthZ request External AuthZ response (allow/deny)

rights reserved. サンプルポリシー package envoy.http.roles import future.keywords default allow := false allow if claims.username in admin_users admin_users := { "alice", "bob" } claims := payload if { v := input.attributes.request.http.headers.authorization startswith(v, "Bearer ") t := substring(v, count("Bearer "), -1) io.jwt.verify_hs256(t, "B41BD5F462719C6D6118E673A2389") [_, payload, _] := io.jwt.decode(t) } { "attributes": { # 中略 "authorization": "Bearer eyJhbGciOiJIUzI1NiIsIn...", # JWT } policy input 例︓管理者としてホワイトリストに追加されているユーザーのみがリソースにアクセスできるポリシーリクエストのヘッダーに含まれる JWT をデコードしてクレームを検証している

rights reserved. 3. AWS Serverless Application Model (AWS SAM) package main import future.keywords legacy_runtime = [ "python2.7", "nodejs12.x", "dotnetcore3.1", ] deny[msg] { some id, res in input.Resources res.Type == "AWS::Serverless::Function" runtime = res.Properties.Runtime contains(runtime, legacy_runtime[_]) msg = sprintf("%s: %s runtime not allowed", [id, runtime]) } Resources: LambdaFunction: Type: AWS::Serverless::Function Properties: Handler: main.handler Runtime: python2.7 CodeUri: dist policy input Conftest という CLI ツールを利⽤ Rego でポリシーを記述し、YAML のような構造化データに対するテストを書くポリシーに違反するリソースの作成、更新、削除を⾃動で防ぐことができる [サポートするデータ形式] CUE, CycloneDX, Dockerfile, EDN, Environment files (.env), HCL, HCL2, HOCON, Ignore files (.gitignore, .dockerignore), INI, JSON, Jsonnet, Property files (.properties), SPDX, TextProto (Protocol Buffers), TOML, VCL, XML, YAML

rights reserved. 4. SQL / GraphQL { "query":"DELETE FROM tbl WHERE id = 1", "ast":{ "Delete":{ "table_name":[ { "value":"tbl", "quote_style":null } ], "selection":{ "BinaryOp":{ "left":{ "Identifier":{ "value":"id", "quote_style":null } }, "op":"Eq", "right":{ "Value":{ "Number":[ "1", false ] } } } } ... 同様に GraphQL などでも応⽤可能とりあえず JSON にできれば OPA は何でも扱えてしまうクエリを抽象構⽂⽊ (AST) としてパースすることで、OPA で扱うことができる例︓where 句のない DELETE ⽂の実⾏を抑制する例︓マルチテナント SaaS で⾃テナント以外のデータへのクエリは禁⽌参考︓OPAを使⽤したSQLの判定

rights reserved. ポリシーベースのアクセスコントロール RBAC (Role-based) ABAC (Attribute-based) PBAC (Policy-based)

rights reserved. OPA による PBAC のメリット o 複数の属性を組みあわせたきめ細やかなアクセス制御 o 動的なコンテキストに応じたリアルタイムな評価 o コード (Rego) として表現されるポリシー Ø 宣⾔的に定義され理解しやすい Ø テストが可能 Ø アプリケーションから独⽴して管理 Ø 軽量で⾼速なポリシーエンジン Ø 汎⽤的 (domain-agnostic)

rights reserved. PBAC in AWS ?

rights reserved. Amazon Verified Permissions New!! 2023/6/13 に GA︕ API ベースのマネージドなポリシーの評価 IdP との連携ポリシーの管理ポリシーの管理

rights reserved. Amazon Verified Permissions ポリシーおよびスキーマを管理し認可を外部化アプリケーション内でのきめ細やかな権限管理およびポリシーのライフサイクル管理過剰な権限を特定し、監視ワークフローに接続することで、⼤規模なコンプライアンス監査もシンプルに⾃動推論を活⽤した複数のアプリケーションを跨ぐ数百万の権限の分析既存の IdP を統合してユーザープロファイル、属性、グループ、役割などを同期アプリケーション開発を⾼速化しつつ、動的でリアルタイムな認可判断によるゼロトラストアーキテクチャのサポート New!! 2023/6/13 に GA︕

rights reserved. ユーザーアプリケーションデータベースポリシーの管理/評価を外部に委譲開発者ポリシーを作成マネジメントコンソール、AWS CLI、 IaC + CI/CD などで管理/運⽤ポリシーの評価を呼び出し、結果を受け取る Amazon Verified Permissions • アプリケーションの疎結合化 • マネージドサービス利⽤による管理コストの削減

rights reserved. Cedar という独⾃⾔語でポリシーを記述 head condition permit( principal in User::"alice", action == Action::"view", resource in Album::"Vacation") when { resource.owner == "alice" }; Can Principal perform Action on Resource with the Context ? この条件において、この⼈はこのリソースに対するこの操作を実⾏できるか︖ Principal: アクションを⾏う実⾏者 Action: 実⾏しようとしている操作 Resource: 操作対象のリソース Context: その他の条件 ”PARC” モデルでポリシーを定義

rights reserved. Amazon Cognito 連携 Amazon Verified Permissions Decisions endpoint 2 (任意) フェデレーション 3 外部 IdP トークン 5 Cognito トークンを使⽤した認可 Amazon Cognito ユーザープール 1 認証 4 Amazon Cognito トークンバックエンド API Amazon API Gateway Lambda Authorizer IsAuthorizedWithToken API の呼び出し • トークンの有効性をチェック • ポリシーの判定結果を取得 Allow/Deny 6 7 8 "dave", "custom:clinicID": "T123", "custom:type": "Client", "custom:personID": "Dave", "runtime:primaryDoctor": "Jane", "cognito:groups": ["Clients", "T123"], "runtime:insuranceOnFile": "true" Amazon API Gateway Enforcement endpoint

rights reserved. まとめ • 効率的なポリシーの管理/適⽤はシステム運⽤の鍵 • コードによってポリシーを運⽤する Policy as Code という考え⽅ Ø アクセスコントロールの⽂脈における PBAC Ø コードを⽤いることによるメリット︓より柔軟な制御が可能、開発者にとって扱いやすい、ドメインに依存せずインテグレーションが容易 Ø ポリシー評価をアプリケーションと分離することで開発⽣産性 UP • まずは OPA や Amazon Verified Permission を試してみましょう

やはりポリシー...！ポリシーは全てを解決する...！OPA で始める Policy as Code

やはりポリシー...！ポリシーは全てを解決する...！OPA で始める Policy as Code

More Decks by NemOps

Other Decks in Technology

Featured

Transcript