Posts

1.この記事を書こうと思った背景 昨今のニュースを眺めていると、クレデンシャル情報(シークレット情報/機密情報)漏洩対策の一環として、ガードレール的なツールを使いたい、またそういったツールを継続的に利用したいというお気持ちが一層強くなる。 そういうわけで Secretlint をはじめとするガードレール的なツールを使おうと思うのだが、SecretlintをCIパイプラインでお手軽に使う方法をひらめいたのでここに書き残しておく。なお、今回の導入対象のCIパイプラインは、GitHub Actionsとしている。というのも https://github.com/secretlint にSecretlintをNode.jsのライブラリとしてGitHub Actions上で扱うサンプルコードが公開されていることから検証のハードルが低いと感じたためである。 secretlint/secretlint-github-actions-example さて、この記事では、SecretlintをCIパイプラインでお手軽に使う方法の他に、誤検知対策としてカンタンにルールを追加する方法についても触れたい。この手のツールは誤検知が大量に作動してしまえば、そのツールはオオカミ少年と認識されてしまいかねない。それだけにSecretlintでは簡易的とはいえ誤検知対策ができるという点は、かゆいところに手が届いているといえるのではないだろうか。 2.解決したい課題とその解決策 まず、具体的な方法論について話す前に前提となる解決したい課題と、ここで提案する解決策について述べておきたい。 2-1.解決したい課題 SecretlintをGitHub Actionsのワークフローでお手軽に使いたい Secretlintを使うためにはDockerかNode.jsが必要である戦う つまり、GitHub ActionsのワークフローのなかでDockerかNode.jsのいずれかを使えるようにセットアップするJobが必要 Node.jsでSecretlintを使う場合、Secretlintのインストールが必要とやや手間 $ npm install secretlint @secretlint/secretlint-rule-preset-recommend --save-dev ルールの追加もお手軽にしたい Secretlintではビルトインのルールが提供されていないが、専用の設定ファイルの .secretlintrc.{yml,yaml,js} (以下、.secretlintrc.json) でルールを利用者側で導入する必要がある Dockerコンテナイメージの場合、推奨ルールセットである、@secretlint/-rule-preset-recommend が同梱されており、イメージをbuildするだけでok https://github.com/secretlint/secretlint#using-docker @secretlint/-rule-preset-recommend Node.jsの場合、上述した @secretlint/-rule-preset-recommend などを.secretlintrc.json で指定し、secretlintコマンドを実行するディレクトリに配置しておかなければならない https://github.com/secretlint/secretlint#using-nodejs # Dockerコンテナイメージを使う場合、Secretlintのインストールは不要 # `.secretlintrc.json　もイメージに同梱されている # ルールを追加したい場合、自分で用意する必要があり、その方法は後述 $ docker run -v `pwd`:`pwd` -w `pwd` --rm -it secretlint/secretlint secretlint "**/*" # Node.jsの場合、以下のコマンドで .secretlintrc.json を生成する必要がある $ npx secretlint --init # .secretlintrc.json はsecretlintコマンドを実行するディレクトリに配置する必要がある $ cat <<EOF > .secretlintrc.json { "rules": [ { "id": "@secretlint/secretlint-rule-preset-recommend" } ] } EOF ところで、SecretlintをGitHub Actionsのワークフローで使うメリットはなんだろうか？ メリットのひとつは、Secretlintの開発者であるazuさんの、 SecretlintでAPIトークンや秘密鍵などのコミットを防止する | Web Scratch で記載されている、一度きりのチェックだと継続的なセキュリティは担保できない という点であろう 一度きりのチェックだと継続的なセキュリティは担保できないので、CIやGitコミットフックなどでプロジェクトに導入する方法を紹介しています。 また、個人環境のグローバルなGitコミットフックに常にSecretlintのチェックを入れることもできます。 ...

1.この記事を書こうと思った背景 Github Actionsでは、schedule ( schedule イベントやスケジュール実行ともいうがここでは、 schedule とする。)というイベントが用意されている https://docs.github.com/ja/actions/using-workflows/events-that-trigger-workflows#schedule 他のイベントとしては、push や workflow_dispatch などがある scheduleは、POSIX 規格の crontab の構文 で表記するのだが、日時の条件指定と曜日の指定はAND判定されるかと思いきや、OR判定されるようだと分かり、Github feedback や Support などで問い合わせた 問い合わせた結果、丁寧に教えていただいたので共有したい [bug] Schedule event’s multiple conditions are judged by OR conditions, not AND conditions #12804 日時の条件指定と曜日の指定のAND判定というのは、たとえば、第1月曜日の午前2:00に schedule を実行したい場合、下記のような書き方を指している(ただし、この書き方ではAND判定とならないので要注意！) on: schedule: - cron: '0 17 1-7 * 1' 2.長いので結論を書く Github Actions の cron で採用されている POSIX 規格の crontab の構文 では日時と曜日が指定されている場合、日時と曜日のOR判定となることが正しい if either the month or day of month is specified as an element or list, and the day of week is also specified as an element or list, then any day matching either the month and day of month, or the day of week, shall be matched. ...

1.markdown/マークダウンファイルをそのまま平文で表示するデモ 百聞は一見に如かず。ということでその様子を GIF で用意した。 2.どんなときに役に立つのか？ markdown ファイルをそのまま表示したいときってどんなときか？ たとえば、こんなときに使えるのではないだろうか。 ソースコードのある箇所を行単位でハイライトをつけるように markdown ファイルでも強調したい。 書きっぷりを markdown 形式で確認したい e.g.いいかんじの Mermaid 記法を見つけたけどこれどうやって書いてんだ！？ 3.どうやるのか？ Github 上で markdown ファイルを開いてから URL の末尾に以下を追加するだけ！ ?plain=1 すると、冒頭の GIF 動画のように markdown のまま表示される。 やってみよう！ 対象の markdown ファイルの URL https://github.com/gkzz/serverless-aws-budget-alerts-to-slack/blob/main/README.md markdown ファイルの URL の末尾に "?plain=1" をつけると、、できた！！ https://github.com/gkzz/serverless-aws-budget-alerts-to-slack/blob/main/README.md?plain=1 一般的なファイルのように行単位でハイライトをつけることもできるぞ！ https://github.com/gkzz/serverless-aws-budget-alerts-to-slack/blob/main/README.md?plain=1#L5:L11 4.おまけ 記事を公開してまもなく、今回ご紹介したマークダウンファイルをマークダウン形式のまま表示する方法ですが、raw とも違うのねとコメントいただきました。 たしかにちがうぞ！！（言われて気がついた。raw の場合、プレーンテキストとして出力しているかんじ。） 2022/03/07 更新 Github の GUI からでもできるよ！と教えていただいた。丸で囲んだボタンを押すと、この記事で紹介している ?plain=1 と同じようにマークダウンをマークダウンのまま表示できる。 ...

1.この記事を書こうと思った背景 AWSの利用料金が想定以上に高くてびっくりしたことがあった AWSの利用料金が想定より高くなったら検知するようにしようと決意したい ↓こういったことが起きないためにも、、 AWSでやらかして3桁万円請求された話 - Qiita 無事できたので、この記事でどうやったか？またいくつか検知する方法があるなかでどういった選定基準を持ったか？書いていきたい ※ サンプルコードはこちら https://github.com/gkzz/serverless-aws-budget-alerts-to-slack 2.前提 AWSの利用料金が想定より高くなったら検知する方法は2022/02/24時点で3種類あり、この記事ではbudget alertsを使った方法を採用している。ただし、各サービスの仕様変更やアップデートなどにより今後は他2つの方法を採用した方がいいということも。 3.環境情報 Serverless Frameworkのバージョンは3.2 $ grep VERSION= /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" $ sls --version Framework Core: 3.2.0 Plugin: 6.0.0 SDK: 4.3.1 $ npm --version 6.14.16 $ nodejs --version v10.19.0 Serverless Frameworkでは環境変数としてAWSのRegionとSlackのincoming webhook urlを使っている 環境変数の使い方や適用方法については以前書いたのでそちらを参照してほしい Serverless Framework 3.xでserverless-dotenv-pluginを使った環境変数の読み込みができなかったのでserverless.ymlを修正した | gkzz.dev　# .env # .envはserverless.ymlと同じディレクトリに配置 # AWS REGION="***" # slack incoming webhook SLACK_WEBHOOK_URL="https://hooks.slack.com/services/***" serverless.ymlを配置したディレクトリをルートディレクトリとみたときのディレクトリ構造 serverless.ymlにLambdaの実行ファイルのパスなどを書くので、treeコマンドの結果を貼っておく treeコマンドの結果からnode_modulesディレクトリは見やすさを考慮して除外した $ tree -L 3 -I node_modules . ## Lambdaの実行環境でnpmパッケージを使うことが出来るようにLambda Layersを使っている # ※ serverless.ymlでLambda Layersをどうやってdeployするのか？については後述 # https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html ├── lambdaLayer │ └── nodejs │ ├── package.json │ └── package-lock.json ├── LICENSE ├── package.json ├── package-lock.json ├── README.md ├── serverless.yml ## serverless deployコマンドでdeployするリソースなどを定義 └── src └── slack-notify.js ## Lambdaの実行ファイル 3 directories, 8 files $ find ./ -type d -name node_modules | grep -Ev "./node_modules/.+" ./node_modules ## Serverless Frameworkの実行環境であるローカルで使う ./lambdaLayer/nodejs/node_modules ## Lambdaの実行環境で使う 4.AWSの利用料金が想定より高くなったら検知する3つの方法 冒頭でお話ししたとおり、AWSの利用料金が想定より高くなったら検知する方法は、今回採用するbudget alerts以外に2種類ある。billing alertsとAWS Cost Anomaly Detectionだ。 ...

1.この記事を書こうと思った背景と書いていきたいこと 1-1.背景 先日、Serverless Frameworkがv3にメジャーアップデートされたことは記憶に新しい Serverless Framework V3 Is Live! そんなServerless Frameworkを2系から3系に引き上げてserverless-dotenv-pluginを使って環境変数が読み込もうとしたところ、以下のようなエラーを引いてしまった $ sls deploy Environment: linux, node 14.19.0, framework 3.2.0, plugin 6.0.0, SDK 4.3.1 Docs: docs.serverless.com Support: forum.serverless.com Bugs: github.com/serverless/serverless/issues Error: Cannot resolve serverless.yml: Variables resolution errored with: - Cannot resolve variable at "custom.REGION": Value not found at "env" source, - Cannot resolve variable at "custom.FAVORITE": Value not found at "env" source このエラーはserverless.ymlと同じ階層のdotenvファイルに書かれた環境が読み込めないというもの 書き方はのドキュメントに詳しく書かれているのでそちらを参照してほしい。ただし、2系で使える書き方であり、3系に対応した書き方はこれから紹介する書き方を採用する必要がある。 Serverless Framework: Plugins エラーを引いたときに使ったserverless.yml frameworkVersionを2から3に修正しただけ service: src frameworkVersion: '3' #frameworkVersion: '2' custom: dotenv: basePath: ./ REGION: ${env:REGION} nodejsVer: nodejs12.x memorySize: 256 timeout: 900 TZ: Asia/Tokyo FAVORITE: ${env:FAVORITE} provider: 略 plugins: - serverless-dotenv-plugin - serverless-offline functions: 略 1-2.この記事で書いていきたいこと そこで今回は以下2点について書いておきたい。 ...