作った。
AWS の Prometheus Exporter では4作目、Prometheus Exporter としては6作目。
なぜ作ったか
もともとのきっかけは AWS IAM で 2FA が有効になっていないユーザがいて、たまたま気づいたが定期的に検知、通知ができてないことから。
AWS Config と SeucrityHub は有効化していたので、mfa の rule は有効になっていた。
ちょっとまだこの違反時の Slack 通知はまだできていないんだが、ついでなのでこの数も送っちゃおう、となった。
AWS Config の cli を見ている。https://t.co/1iTHvw2UCf get-compliance-details-by-config-rule 該当 Rule の結果、COMPLIANT かどうか、そして対象の Resource も得られるんだけど、Resource Type "AWS::IAM::User" と ResourceId に ID だけ得られて厳しい。この ID だけでは何か識別できない。
— Takeshi Kondo (@chaspy_) February 2, 2021
であれば Rule 一覧を取って結果 Compliant / Noncompliant の数だけを metric として出して詳細は見に行ってね、ぐらいが落とし所かなあ。
— Takeshi Kondo (@chaspy_) February 2, 2021
あーこれ使えば https://t.co/6ITgk1I6o6 rule とそれに対して COMPLIANT か、NON_COMPLIANT ならその数が得られるのでいったんこれ metric にするだけでもまぁ良さそう。
— Takeshi Kondo (@chaspy_) February 2, 2021
Go sdk はこれ https://t.co/TngJw9Y8XL
— Takeshi Kondo (@chaspy_) February 2, 2021
使ってる API
describe compliance by config rule
go sdk
今回は特にシンプルで、この API 1つから帰ってくる Compliance by Config Rule を metric として送っていて、Value としては Capped Cound を出している。
https://docs.aws.amazon.com/sdk-for-go/api/service/configservice/#ComplianceByConfigRule
type ComplianceByConfigRule struct { // Indicates whether the AWS Config rule is compliant. Compliance *Compliance `type:"structure"` // The name of the AWS Config rule. ConfigRuleName *string `min:"1" type:"string"` // contains filtered or unexported fields }
type Compliance struct { // The number of AWS resources or AWS Config rules that cause a result of NON_COMPLIANT, // up to a maximum number. ComplianceContributorCount *ComplianceContributorCount `type:"structure"` // Indicates whether an AWS resource or AWS Config rule is compliant. // // A resource is compliant if it complies with all of the AWS Config rules that // evaluate it. A resource is noncompliant if it does not comply with one or // more of these rules. // // A rule is compliant if all of the resources that the rule evaluates comply // with it. A rule is noncompliant if any of these resources do not comply. // // AWS Config returns the INSUFFICIENT_DATA value when no evaluation results // are available for the AWS resource or AWS Config rule. // // For the Compliance data type, AWS Config supports only COMPLIANT, NON_COMPLIANT, // and INSUFFICIENT_DATA values. AWS Config does not support the NOT_APPLICABLE // value for the Compliance data type. ComplianceType *string `type:"string" enum:"ComplianceType"` // contains filtered or unexported fields }
type ComplianceContributorCount struct { // Indicates whether the maximum count is reached. CapExceeded *bool `type:"boolean"` // The number of AWS resources or AWS Config rules responsible for the current // compliance of the item. CappedCount *int64 `type:"integer"` // contains filtered or unexported fields }
struct はこんな感じの階層構造になってる。
ComplianceByConfigRule
|__Compliance
|__ComplianceContributorCount
|__CapExceeded
|__CappedCount
|__ComplianceType
|__ConfigRuleName
ConfigRuleName が rule 名、ComplianceType が COMPLIANCE か NONCOMPLIANCE か。CapExceeded が、よくわかんないけどルール違反が 25 をこえたかどうか。Capped Count が違反してる数で、25以上の場合は25になる。
課題
Capped Count を Value として送っているので、そもそも ComplianceType が COMPLIANCE - ちゃんと遵守している場合、value が 0 となってしまい、どの rule が守られているのかという情報は送信されない。考えたがどうにもしょうがないような気もする。あと気にすべきは NONCOMPLIANCE なものの数なのでやむなしかなと。
COMPLIANCE の rule が全部で何個、NONCOMPLIANCE の rule が全部で何個かを出すなら別の API と別の metrics として export すれば良いと思うが、まぁいったんこれは別になくてもいいかなと思った。見たい気もするけどなくても良い。
結果
こんな感じ。
AWS MFA の数だけ注目してみるとこんな感じ。7人もいるのでどげんかせんといかん。
まぁルールを完璧にいきなりするのは難しいので少しずつ、できるところから。
次回
AWS 編は Cost が気になっているのだけれど、ちょっとおやすみして、CircleCI Insight に挑戦する予定。
CircleCI の Insight API に想いを馳せている。https://t.co/xYcVo8IO5F CI の時間を分析する場合、うちの場合は差分検知をやってる関係で、差分がない場合 CI が立ち上がるがすぐ halt するみたいなことをやってるせいで正しい統計情報が取得できないため、別 workflow を nightly で全部ぶんまわし、
— Takeshi Kondo (@chaspy_) February 7, 2021
その分析結果を Insight API で取得して、長期的な CI 時間のトレンドを取得できないかと考えている。nightly でやる理由は前述の差分検知の問題が1つ。あとは実際の CI 実行後に Job の CI 時間を Datadog 等に Push するアプローチは Sparse metrics となってしまう。
— Takeshi Kondo (@chaspy_) February 7, 2021
Sparse metrics はいわゆる Event 的にデータが蓄積されるため、分析に向かない。Line でつなげばそれらしきトレンドは見えるものの、push だと実行頻度も Job によってまちまちなので、十分なサンプル数を得られない。そこで Nightly で常時・定期実行し、それを分析した結果を Gauge として
— Takeshi Kondo (@chaspy_) February 7, 2021
貯めることで十分なデータ量が得られ、分析もしやすくなると考えている。Datadog に Histgram として送るのはどうかと考えたが、その統計情報の Time Window, Flash Interval は結構短かったはずで、（1分とか？ドキュメントに載ってないが）要件にマッチしない。https://t.co/DghjLAXxja
— Takeshi Kondo (@chaspy_) February 7, 2021
https://t.co/KBvS95gsS8 summary metrics for a project's workflows が workflow の分析によさそう。これ自体が metrics.duration_metrics として min, median, p95 など計算済み情報を提供してくれる。time window も指定できるので、Nightly を1時間に一回なら 24h、1日1回なら 7days、30days とか
— Takeshi Kondo (@chaspy_) February 7, 2021
こっちが job に対してなので、この2つの api を使えばなんとでもなりそう。https://t.co/ube4vXWsTM なお CircleCI GUI の Insight からもこういう統計情報は得られるが、特定の Time Window での統計値のみで、推移は追えない。
— Takeshi Kondo (@chaspy_) February 7, 2021
というわけで circleci-insight-prometheus-exporter のネタができた。いったん毎時走ってる nightly workflow が既にあるのでそれを対象に使ってみよう。
— Takeshi Kondo (@chaspy_) February 7, 2021
