IDS/IPSとは?
IDS/IPSを導入する機運がありつつも、ネットワークセキュリティ何も分からんといった感じなので調べたことをまとめていく。
また、AWSがメインな環境ではIDS/IPS導入ってどうやるのというのを調べた。
次回は実践編を書きたい。
そもそもIDS/IPSとは?
ざっくりこんな感じ
IDS (Intrusion Detection System)
- 不正侵入検知システム
- 不正侵入を検知すると報告する
NIDS(ネットワーク型IDS)
- ネットワークを監視するために使われるIDS
- パケットを監視する
- FW → NIDS → Webサーバ
- 通信内容が暗号化されると検知できない
HIDS(ホスト型IDS)
- 保護したいコンピュータにインストールする
- OSやアプリケーションが生成するシステムログ、監査ログ、イベントログなどの情報を利用して検知
- 暗号化されていてもホスト側で複合化されたものを使用して検知できる
IPS(Intrusion Prevention System)
- 不正侵入防止システム
- FWで検知できない不正侵入を遮断することができる
NIPS(ネットワーク型IPS)
- 通信経路(インライン)を考慮しないと遮断できないので注意。
- 通信内容が暗号化されると遮断できない。
HIPS(ホスト型IPS)
- 保護したいコンピュータにインストールする
- 暗号化されていてもホスト側で複合化されたものを使用して検知できる
ではAWSでは何を使うといいのか?
AWS Network Firewall
3rd party製の何かを買ってインストールして使うのもいいが、マネージドで済ませられるならそれに越したことはないかなぁ。と考えていた。
調べてみると比較的新しい機能としてAWS Network Firewallというものがあったのでそれを調べてみた。
概要
VPCのサブネットに配置するマネージドなFirewallサービス
トラフィックの負荷に基づいてファイアウォールの容量を自動的にスケールアップまたはスケールダウンする
AWSパートナー製品と統合することも可能。
ルールグループ
AWS Network Firewall のルール グループ
以下の2種類に大別される。
- AWSマネージドルールグループ
- AWSにより自動的にアップデート
- AWSが提供するルールで問題なし。と組織内で妥当性について合意を取れればすごい便利に感じる。
- 現時点では以下の2種類がサポートされている
- Domain list rule groups
- Threat signature rule groups
- Suricata 互換のステートフル マネージド ルール グループをサポート
- 2022/7 からサポート開始
- AWSにより自動的にアップデート
Suricata
非営利団体Open Information Security Foundationが管理する。
用語集
調べていてピンとこなかったものを調べた。
- 5-tuple
- 以下のIPヘッダ上の5つの要素を示す
- ソースアドレス
- 宛先アドレス
- プロトコル
- ソース・ポート
- 宛先ポート
- 以下のIPヘッダ上の5つの要素を示す
- シグネチャ型
- 「不正」な通信を定義し、パターンマッチングによって検知する。
- アノマリ型
- 「正常」な通信を定義し、それ意外をすべて不正として検知する。
参考資料
AWS Black belt Network Firewall 入門
AWS Network Firewall – New Managed Firewall Service in VPC
2022振り返り
仕事
3月からSREとして入社して約10ヶ月間経過した。
チームメンバーの技術力が高くてついていくのに必死だった。
社会人生活6年目、一番技術力が向上一年だったかもしれない。
手を動かすこともかなり増えてきた。
反面、自己肯定感が人生最大級ですり減った一年とも言える。
単純に知識が足りないというのもあるんだけど、あるひとつの出来事から学ぶことができる量が少ないと思えてきた。
1冊の本から学んでいることが少ないというか、なんと言えばよいのか。単純に勉強のコスパが悪い。
来年は学び方から直さないといけないと思っているし、なぜなにを繰り返しながら突き詰めていけるような性格を形成したい。
性格特性を変えることとかできるのか?
キャリア
キャリアに対しての漠然とした不安を常に抱えている。
5/21に書いたキャリアについてのブログでも同じように不安を抱えていた模様。
約半年も経過してもあまり成果が出てないような気がしてくる。
以下は、最近Twitterで流れてきたスライド。
キャリアの悩みがなくなることなんて無いと語られているがその通りだと思う。
キャリア = 経歴。チャレンジしてきたこと。肩書きとは別物。
横文字にするとなんか理解が漠然となる気がしているので、これから「キャリア」という言葉を見たら脳内で「経歴」に自動で置き換えるようにしよう。
3ヶ月前にやったことなんて忘れてしまうのはあるあるなので、ちゃんとアウトプットをする場を作ろう。
多分だけど、アウトプットする場がちゃんと1つにまとまっていて、1年の間にそれが積み重なっていけば自信になると思う。
来年はアウトプットを増やそう。最低限1ヶ月に1回は何かしらにアウトプットをするという目標にしたい。
Qiitaデビュー
Qiitaに投稿するのすごい苦手で自分のはてなブログに閉じこもってダラダラと文章書いてきた。
だけど会社のアドカレに参加するという目標を立ててしまったのでqiitaデビューした。
企業ブランドを損なわないように...とか、文章の体裁を整えたり、膨大なインプットが必要だったのでかなりストレスだった。
結局は、喉元過ぎれば熱さを忘れるな感じで投稿し終えたあとは特になんとも思わなくなった。
プライベート
8月に父が亡くなってから心身ともに休まらず、忙しい日が続いた。
司法書士を雇わずに相続の手続きをしたので、預貯金、不動産登記、父の確定申告、職場に残してあった荷物の整理も自分でやらなければいけなくて辛かった。
特に相続登記に関しては遺産分割協議書の作成が必要。
遺産分割協議書自体に書式に細かいルールはなかったりするんだけど、相続登記で使用する場合は登記事項証明書に沿って細かく記載する必要があるので辛い。
司法書士を雇うと十万円以上はかかってくるのでそれをケチったワケだが、それがよくなかった。
依頼範囲にもよるけど、戸籍謄本類も役所に取りに行ってくれるらしいけどそこまではいらないかも。
書類はとりあえず一回区役所に行けばいいし、マイナンバーカードがあれば印鑑証明書はコンビニで発行可能。
新型コロナウイルス対策で税務署、法務局あたりは窓口対応してくれない。
自分で調べて書類を送付したあと、問題があれば補塡するという手順が非常にめんどくさかった。
積極的に時間はお金で買っていくスタイルにしたい。
まだいくつかやらなければならないことが残っているので1月中にケリをつけたい...
ふるさと納税
今年初めてふるさと納税をしてみた。
2000円を自己負担でその他を住民税の控除にあてることができるという神施作だったんだけど今年が初。
高級肉とかはぶっちゃけ家で焼いてもうまくはないので、コスパ重視の米を狙うのがよかった。
米は基本的に食べないが、姉が自炊で大量に米を消費するので家計に優しい。
Netflix
年間契約をしていたんだけど、勉強時間が奪われるのでやめた。
暇つぶしとしての役割ももってたんだけど、「暇があるなら勉強しろ」という強迫観念があって素直に楽しめなくなった。
ただ、ウェンズデーみたくてすでに復活したい気持ちがある。
Podの終了
API server内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される。 削除中のPodに対してkubectl describeコマンドを使用すると、Podは「終了中」と表示される。 Podが実行されているNode上で、Podが終了しているとマークされている(正常な終了期間が設定されている)とkubeletが認識するとすぐに、kubeletはローカルでPodの終了プロセスを開始します。 Pod内のコンテナの1つがpreStopフックを定義している場合は、コンテナの内側で呼び出される。猶予期間が終了した後も preStopフックがまだ実行されている場合は、一度だけ猶予期間を延長される(2秒)。 備考: preStopフックが完了するまでにより長い時間が必要な場合は、terminationGracePeriodSecondsを変更する必要があります。 kubeletはコンテナランタイムをトリガーして、コンテナ内のプロセス番号1にTERMシグナルを送信する。 備考: Pod内のすべてのコンテナが同時にTERMシグナルを受信するわけではなく、シャットダウンの順序が問題になる場合はそれぞれにpreStopフックを使用して同期することを検討する。
久々に読んだら全然わからん...となってしまったので思い出しながらメモ。
終了処理はSIGTERM、SIGKILL(猶予期間terminationGracePeriodSecondsを超えた場合)の順に実行される。また並行してServiceからの除外処理は非同期で行われる。
Serviceの除外処理とは、kube-proxyによりiptabelsが更新されることにより、新規の接続がなくなること。
終了開始とともにServiceから除外されないため、終了処理中にServiceからの新規接続を受け入れてしまう期間が発生してしまう。
それを防ぐためにpreStopを設定する。
preStopを設定することにより、SIGTERM処理の前に任意のコマンド、例えばsleepを入れることにより一定期間待機させることが可能。
SIGKILLはterminationGracePeriodSecondsを超えたときに送信される。
terminationGracePeriodSecondsはデフォルトで30秒。もしpreStop処理がterminationGracePeriodSecondsを超えてしまうような設定は避けるべき。
図示するとこうなる。
AWSの薄い本 IAMのマニアックな話
1章 AWSとIAM
2章 IAMの機能
- IAMの機能
- IAMユーザ
- ID と PASSWORD
- アクセスキーID と シークレットアクセスキー
- アクセスキーの発行は原則しない。必要なときに最小権限で発行する。
- IAMユーザの発行単位
- 実際に誰が利用していたのかを把握するため、利用者毎・プログラム・ツール毎に発行する
- IAMグループ
- 同一の役割をもつユーザをグループ化し、権限を付与できる。
- Admin, Developer...
- IAMロール
- AWSサービス、アプリケーションに対して操作権限を付与する
- IAMユーザを割り振れない場合等に使う
- パーミッション・バウンダリー
第3章 IAMチュートリアル
- GUIでの操作の解説
- IAMの許可・拒否ポリシーの挙動
- 明示的なDeny > 明示的なAllow > 暗黙的なDeny(デフォルト)
第4章 IAMポリシーのデザインパターン
ホワイトリストパターン
- 許可する権限のみを付与
- 他はデフォルトの挙動で暗黙的なDenyで制限される
- メリット
- 必要最小限の権限のみを付与するためセキュリティにおける信頼性が高い
- デメリット
- 事前に付与する権限が決まっていないと付与することができない
- 探索的に開発を進めていく場合、都度、権限付与する必要があり、IAMポリシーを管理する手間がある
- 業務や運用設計が確率している場合、高いセキュリティを求められる場合に有効
ブラックリストパターン
- 許可してはいけない権限を剥奪する
- ex. NotActionでIAMの権限以外の権限を許可した後にパスワード変更等の権限を明示的にAllowで設定する。
- メリット
- 禁止事項のみを定義するだけでいいのでIAMポリシーの設計・設定が最小でよくなる
- 利用者は高い自由度を持つことができる
- デメリット
- NotActionで指定するため、AWSに新しいサービスが始めると自動的に新しい機能が使えるようになってしまう。
- AWSの権限は暗黙的なDenyのため、新しいサービスを使いたくても権限がなく、すぐにサービスを利用したくても使えないが、ブラックリストパターンではすぐに利用できる。
- 探索的な開発を行う場合等に適している。
ハイブリットパターン
第5章 IAMグループのデザインパターン
- 以下の2パターンには機能的な優劣は存在せず、運用面で組織やチームにあったものを選択すればよい
- 複数のグループに所属するパターン
- 必須の全ユーザ向けIAMポリシーを持つIAMグループに所属させ、開発者向けまたは運用者向け等の役割毎IAMグループに所属させる。
- グループ内に複数のポリシーを設定するパターン
- ユーザーが一つのグループに所属するという前提に権限を管理する
- 1つのグループにしか所属しないため、シンプルさがある
第6章 IAMとセキュリティ
- すべてのIAMユーザにMFAを設定しておくこと
- 将来的に特権ユーザーになる場合があるため、初期段階ですでにMFAの設定をしておく
- Lambdaリソースベース権限
- AWSリソースへのアクセスはIAMポリシーで管理されていて、Lambda関数の実行ロールとして紐付けることができる。
- Lambdaはリソースベースのポリシーを利用することができ、リソース毎に他のアカウントに使用許可を与えることができる
- リソースベースのポリシーはIAMの権限を利用せずともアクセス権限を得られることになるので最小権限を付与することが望ましい
- インターネット公開系の権限
- EC2のように権限が多岐に渡るものはネットワーク系の操作を明示的に拒否する方法と併用するとよい
- S3へのアクセス元権限はIAMポリシーを使って制限を行うよりも、S3側のバケットポリシーを使うとよい。
- IAMでリソース制限をする際にはプライベートIPを使用することができないため、InternetGatewayを通らない場合は、VPCのIDを元に権限を付与する。
- アクセスキーの原則禁止
- アクセスキー・シークレットアクセスキーの流出防止策はあるものの、作らないに越したことはない。
- Capital Oneは2019/7に1億人を超える個人情報の流出事件
第7章 IAMの運用
- セキュリティ保持のために手間がかかる運用であればいつかは形骸化する
- IAM運用の目的
- AWSを安全な状態の保持
- 維持するために手間がかからず、利用者によってセキュリティレベルの差異がでないように標準化する。
- ツール・プログラム利用・関係者の洗い出し
- AWSアカウント(ルートユーザ)は原則的に使用しない
- アカウント作成後は、ルートユーザを使用せずとも支障がないような設定を行うべき
- IAMユーザの管理
- 最小権限の付与
- 不要になったユーザーの削除
- Croud Trailで利用状況のログを取得、Configで設定変更の監視をするなどして定期的にIAMユーザの棚卸しをすべき
- 人間用のIAMユーザー
- ユーザー毎に作成し、共有アカウントの作成は禁止
- 異動や退職などの入れ替わりに応じて棚卸しルールを作成する
- CLIやプログラムから利用するIAMユーザー
- 人の出入りに関しては比較的わかりやすい
- プログラムから利用されなくなったIAMユーザは観測しにくい
- IAMユーザごとの担当者を明確化する
- 最終利用日から一定期間過ぎたIAMユーザーは継続確認を行う
- アクセスキーの管理とCLI
- アクセスキーは限られたIAMユーザーのみで作成する
- アクセスキーを作成するIAMユーザーの権限は最小にする
- CLIでもスイッチロールは可能なため、必要な場合はIP単位でIAMユーザの制限をし、スイッチロールする
- MFA未利用時に権限を制限し、MFA利用を促す
- MFAを設定していない場合は、IAM以外の権限を拒否するポリシーをアタッチすることでMFAの設定を促す
- マルチAWSアカウントでの運用
- IAMユーザをそれぞれのアカウントで作成するのは手間がかかる
- 踏み台のAWSアカウントを作成し、そのアカウントでIAMユーザーを作成ののちにスイッチロールすることで手間が省ける
第8章 IAMとCloudFormation
- CloudFormaion等のIaCでAWSアカウントを管理しておけば手間を省き、人的なミスを防ぐことができる
第9章 IAMのテンプレート集
- CloudFormationのテンプレートがあったが割愛する
- 共通ポリシー
- 自身のパスワードをMFAの設定権限
- IP制限とMFA必須化のポリシー
- 管理者グループ
- 全権限の付与
- 全ユーザからのSwitchRoleをされることを抑制するポリシー
- ロールにスイッチ可能なユーザを記載するパターン
- 特定ユーザーにスイッチロール可能な権限を付与するパターン
- ネットワーク管理者グループ
- 開発者グループ
- 多くのリソース制御が必要
- 本書ではPowerUserAccessとネットワーク権限、Lambdaの権限付与をしているが、組織に適したポリシーをアタッチすることが必要
- オペレーターグループ
- どこまでが職務範囲かに依存
- AWSサポートに問い合わせが必要な場合は、AWSSupportAccessを付与する
- 経理担当者グループ
- BillngにアクセスするためのAWS管理ポリシーをアタッチ
- お一人様AWS(個人開発等)
- Admin権限を普段扱いせず、参照権限のみを付与
- 必要に応じて管理者ロールにスイッチロールするのが安全
第10章 IAM以外のAWSサービスの活用
CloudTrail
- 誰がどの操作を行ったのか実行履歴ログを取得することができる
Config
- AWSリソースがどういう状態か、状態に対してどのようなアクションをするかを設定できる
- ex. EC2インスタンスにタグでNameをつけることを必須化する運用ルールを策定し、それを満たしていない場合、強制的にシャットダウンさせる
GuardDuty
- 驚異検出と継続的なモニタリングができ、それに対する防御を機械的に実行する
ControlTower
- 複数のアカウントの設定及び管理するサービス
SecurityHub
- 複数のアカウントの状況を一括してモニタリングするサービス
Security Hub Orgnization
Security Hub
OrganizationでSecurity Hubを有効にしてみました。
SecurityHubの有効化はAWS Configの有効化が必須なのが注意。
検出結果はChatbotを使用してSlackに通知している。
構築はほとんどTerraformで行った。
Chatbotはawscc providerを使用すれば設定できますが、ChatbotをSlackのWorkspaceに招待することができず、AWS Consoleから操作しました。
もしかしたら見逃しているだけかも...
適用したルールセットはSecurityHubを有効化したときにデフォルトで設定される以下。
Slackへの通知は以下のように行われる。
検出結果1つにつき1件のコメントが通知されるので、場合によっては大量に通知がくる。
上位のSeverityだけをフィルタリングをEventBridgeのルールで設定できるので、絞っておいたほうがようさそう。
Security Hubの実行スケジュールは12時間毎に定期的に行われるため、対処しない限りは検出される。
一応、一度しかSlackへ通知しないといったフィルタリングもできるが、一度見逃したらアウトという感じになるのでやめたほうがいいと思う。
困ったこと
EventBridgeのデバックが難しい
Security HubというかEvent Bridgeの問題。
Event Bridge -> ルール -> 対象ルール名 -> モニタリング と遷移してCloudWatchから失敗していることが分かるが「Failed Invocations」以外の情報がない。
難しいというか不可能に近い。Event BridgeでECSタスクを発火させる場合はCloudTrailから失敗理由を終えたりするけど、今回のような構成では無理。
こういう場合はだいたいターゲット側(今回で言えばSNS)が原因のことが多いためそこから探っていく。
通知問題
大きく2つ。
- 見辛い。
ConsoleからSecurity Hubを開けば何のルールで引っかかったのか、改善方法等が見れるがやっぱり見辛い気がする。
多分慣れ。通知のフォーマットが見辛いならLambdaを挟んでなんとかするしかない。
といっても見やすさは個人差があるのでそこまでやるメリットがあるかは不明。
慣れたほうがコスパよさそう。
- 大量通知がくる
Severityでフィルタリングすればまぁ抑制することはできる。
が、大量のアカウントを作成していたり、AWS Foundational Best Practices に乗っ取らず運用してきた場合は中々難しい。
不要になったIAMはちゃんと削除してる?とか。そのレベルからの話もある。
ちゃんと運用しよう。に尽きる話ではある。が今後どうしていくか?というところにちゃんとリソースを投下しないと厳しい。
チーム内で一定期間専任をつけたりとかした方がいいと思う。
運用
公式のドキュメントにもあるように無効化したいルールが出てきた場合。
TerraformでもCosoleからでもできるが、その判断が難しい。
無効化するにあたっての根拠を整理し合意を取るというコストは割と大きいと思う。
(コストといってよいのか?)
隔週でMTGを行うとかが最初の1歩としてはよさそうな気がしている。
trivy入門してみる ①
trivy
Trivy (tri pronounced like trigger, vy pronounced like envy)
とのことなので「トリィヴィー」と発音するのが正しそう?
tfsecに続き、trivyを使ってterraformの静的解析をしてみる。
trivyは内部でtfsecを使って静的解析を実行している。
AquaSecurity社がtfsecを買収してtrivyに統合した結果が今とのこと。
tfsecとの違い
親切なことにtrivyのドキュメントに書かれていた。
実運用上で気になる差異はこんな感じ
Show Issue Lines
- GHAで走らせたりするとissueを作成してくれるのだが、対象箇所をissueに記載してくれない模様
Filtering by Severity
- うれしい機能。trivyはオプションとしてSeverityを指定してフィルタリングできる
さっそく使ってみる
- scan対象のterraformコード
resource "aws_instance" "nginx" { ami = "ami-0218d08a1f9dac831" vpc_security_group_ids = [aws_security_group.default.id] instance_type = "t3.micro" tags = { Name = "nginx_server" } user_data = <<EOF #!/bin/bash amazon-linux-extras install -y nginx1 systemctl restart nginx.service EOF } resource "aws_security_group" "default" { name = "ec2" ingress { from_port = 80 to_port = 80 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } ingress { from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } }
# CRITICALとHIGHのみをフィルタリング $ trivy config --severity CRITICAL,HIGH .
検出結果はtfsecと大差ない感じ。
tfsecのignoreがそのまま使える
内部的にtfsecを使っているのでそのままtfsecのignoreが使える。
ingress { from_port = 80 to_port = 80 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] #tfsec:ignore:AVD-AWS-0107 }
ただ振られているIDはtfsecとは異なる。
tfsecはv1.0.0からルールが変更されて「AWS000」等のlegacyな一見して分かりにくいIDから変更になっている。
ここはtrivyも追従してもらいたいなと思う。
Rego
Regoを用いてカスタムポリシーを記載できるのだが、個人的には分かりにくいと感じる。
学習コストはある程度存在している。
そして注意したいのが、「Regoのカスタムポリシーはterraformに対応していない」ということ。
正確にはHCLは対応していてもTerraformHCLには対応していない。
ではどうするのかというと、terraform show -json で plan結果をJSONに起こしてOpen Policy Agentが読み取れる形式に変換してあげる必要がある。
terraformの静的解析ではtfsecに軍配が上がりそう・・・?
ただ、k8s manifest も Dockerfileにも対応しているtrivyに一本化したいという気持ちもあるのは確か。
tfsec入門してみる
セキュリティの機運が高まってきて、tfsecを導入しようというような動きがあるので事前に学習してみる。
- tfsecのinstall
$ brew install tfsec
- tfsecでチェックするためのterraformのコードを用意
- ガバガバな全開放のセキュリティグループをnginxを入れたEC2インスタンス立てる
resource "aws_instance" "nginx" { ami = "ami-0218d08a1f9dac831" vpc_security_group_ids = [aws_security_group.nginx_security_group.id] instance_type = "t3.micro" tags = { Name = "nginx_server" } user_data = <<EOF #!/bin/bash amazon-linux-extras install -y nginx1 systemctl restart nginx.service EOF } resource "aws_security_group" "nginx_security_group" { name = "ec2" ingress { from_port = 80 to_port = 80 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } ingress { from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } }
- tfsecを実行
- 実際はもっと大量にでていますが、省略して一部のみ。
Result #1 CRITICAL Security group rule allows ingress from public internet. ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── main.tf Line 22 ───────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 22 │ cidr_blocks = ["0.0.0.0/0"] ───────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── ID aws-vpc-no-public-ingress-sgr Impact Your port exposed to the internet Resolution Set a more restrictive cidr range More Information - https://aquasecurity.github.io/tfsec/v1.19.1/checks/aws/vpc/no-public-ingress-sgr/ - https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group_rule#cidr_blocks ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
上記で引っかかっているのは↓のようです。
aws-vpc-no-public-ingress-sgr
というIDで管理されているみたい。
resource "aws_security_group" "nginx_security_group" { name = "ec2" ingress { from_port = 80 to_port = 80 protocol = "tcp" # tfsec:ignore:aws-vpc-no-public-ingress-sgr cidr_blocks = ["0.0.0.0/0"] } }
ID指定で一旦無視させることでtfsecのチェックから除外することができる。
なお、workspace単位でignoreすることもできるので、途中からtfsecを導入してどえらい量の警告が出た場合は一旦workspace単位で無視してみると導入しやすそう。
危険な状態である。という認識を得るだけでも意味がある。
どうせならGHAで動かしたいので探してみるといくつかあった。
今回はRun tfsec PR commenterを使ってみる。
name: tfsec-pr-commenter on: pull_request: workflow_dispatch: jobs: tfsec: name: tfsec PR commenter runs-on: ubuntu-latest steps: - name: Clone repo uses: actions/checkout@master - name: tfsec uses: aquasecurity/tfsec-pr-commenter-action@v1.2.0 with: tfsec_args: --soft-fail --force-all-dirs github_token: ${{ secrets.GITHUB_TOKEN }}
全ディレクトリを見てほしかったので、 --force-all-dirs
を追加。
その他に使える引数は以下。 tfsec --help
で出てくるのはだいたい使えるみたい。
結果。自動でPRにコメントしてくれます。
中々使い勝手がよいです。デメリットは特にはないかな・・・?