OPAをAWS Lambdaへデプロイ
この記事はOPA/Regoアドベントカレンダーの17日目です。 今回はOPAの機能をAWS Lambdaで実装する方法について紹介します。 AWS Lambda におけるOPA利用の戦略 AWS LambdaはFargateやGCP Cloud Runとは異なり、純粋に「関数」としての機能を提供しています。関数の呼び出しも各言語のSDKを経由する必要があり、既存のバイナリをそのまま利用するのは困難です。つまり GCP Cloud Run 、あるいは AWS ECS・Fargateのようにコンテナイメージやバイナリをそのまま使うことはできません。そのため、次の2つのどちらかの方針を検討する必要があります。 1) ランタイムを組み込んだLambda関数を自作する github.com/open-policy-agent/opa/rego パッケージを取り込んだGo言語ベースのLambda関数を
Regoの基礎（Safety）
package example p := { "blue": 1, "red": 0, "yellow": 2, } result[x] { not p[x] == 0 } % opa eval -b . data { "errors": [ { "message": "var x is unsafe", "code": "rego_unsafe_var_error", "location": { "file": "example.rego", "row": 9, "col": 5 } } ] } OPAはルールが有限個の入力と出力を持つことを保証するために Safety という概念を持っています。ちゃんと定義された変数のみが ドキュメントでは "Safety" は以下のように定義されています。 Safety: every variable appearing in the head or
Goでセキュアにロギングするzlog
TL; DR Goで秘匿値をログに出力しないようにする zlog というロガーを作りました。 以下、経緯や使い方の説明です。 背景：サーバーサイドにおけるロギングと秘匿値の問題 Webサービスを含む多くのサーバーサイドのサービスでは、サービスの挙動に関するログを出力・記録しておくのが一般的です。継続的にログを出力しておくことで、トラブルシューティングやデバッグ、セキュリティインシデントの対応や監査、性能改善の手がかりなどに活用することができます。ログに含まれる情報が多いほど問題を解決するための手がかりが増えるため、（限度はあるものの）なるべく多くの情報を掲載する、あるいは設定によって情報量を増やせるようにしておくと便利です。 しかし一方で、サーバーサイドで出力するのは望ましくない情報もあります。 認証に利用される情報：パスワード、APIトークン、セッショントークンなど、それを使うことで別の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
