github actionsのGITHUB_TOKENの権限はデフォルトreadonly

久しぶりに新しいツールを作って、github actions+goreleaserでリリースをしようとしたら何故かreleaseにバイナリをアップするところで403エラーが発生しました。

(https://github.com/reiki4040/rnss/actions/runs/8963717671/job/24614599363#step:4:58) 
⨯ release failed after 1m55s error=scm releases: failed to publish artifacts: could not release: POST [https://api.github.com/repos/reiki4040/rnss/releases:](https://api.github.com/repos/reiki4040/rnss/releases:) 
403 Resource not accessible by integration []

元々homebrew tap用のリポジトリにもpushするために別のトークンは設定していますが、そこではなく標準で使うGITHUB_TOKENが使われる場所で発生しています。

何か変わったのかなと思い設定を見てみると、リポジトリのSettings>actions>general > 下部のworkflow permissionsにありました。今回作ったリポジトリはRead repository contens and packages permission になっていたので、どこかのタイミングでリポジトリ作成時のデフォルトがreadonlyに変わったようです。

ここをRead and write permissionsに変更し、workflowをre-runしたら無事にreleaseがpublishされて無事解決しました。

いつ変わったか調べたら2023/02/02のアナウンスがあったので1年ちょっと前からでした。

github.blog

aws-sdk-go-v2でassume roleしてAPIを呼ぶ

クロスアカウントを使うことがあったのと、そろそろv2をちゃんと使わないとなということでaws-sdk-go-v2を使ってassume roleする方法を調べました。EC2のDescribeInstancesを呼んでインスタンスリストを出すだけのサンプルを実装しています。コード全体はここに上げてあるのでみてみてください。MFAは無しとstdinからの入力のパターンに対応しています。

github.com

使い方はSDKドキュメントにしっかり書いてあってその通りなんですが、最初からそこは見つけられず、stack overflowでパッケージを把握して見に行きました。

サンプルからの抜粋

cfg, err := config.LoadDefaultConfig(ctx,
    config.WithRegion("ap-northeast-1"),
)
if err != nil {
    log.Fatal(err)
}

// ...中略...

if optRoleArn != "" {
    stsClient := sts.NewFromConfig(cfg)
    var provider *stscreds.AssumeRoleProvider
    if optMFAArn != "" {
        provider = stscreds.NewAssumeRoleProvider(stsClient, optRoleArn, func(o *stscreds.AssumeRoleOptions) {
        o.SerialNumber = aws.String(optMFAArn)
        o.TokenProvider = stscreds.StdinTokenProvider
        })
    } else {
        provider = stscreds.NewAssumeRoleProvider(stsClient, optRoleArn)
    }

    cfg.Credentials = aws.NewCredentialsCache(provider)
}

// 後はEC2など必要なAPIの呼び出し
cli := ec2.NewFromConfig(cfg)

• aws-sdk-go-v2で必ずやるcfg, err := config.LoadDefaultConfig()
• stsサービスのクライアントを作り、変身先のRoleARN(arn:aws:iam::<account id>:role/<role-name>)、必要な場合はMFAのARN(arn:aws:iam::<account id>:mfa/<user name>)と今回は標準入力からのMFA codeの受付を担うstscreds.StdinTokenProviderを使ってAssumeRoleProviderを作成
• cfgにそのAssumeRoleProviderを設定し、その先はassume roleを行わない場合と同じ各種APIの呼び出し方法

ちなみに同じcfgを使っていれば処理中ではMFAは1回目だけ*1聞かれます。サンプルではその確認のために2回呼んでいます。もちろんコマンド起動ごとにはMFAを聞かれます。

他にも、Stack overflowの回答ではコメントアウトしてありましたが、ClientLogModeという設定があるのもわかりました。サンプルではSigningのログを出すオプションを付けています。リクエスト/レスポンスログなども出せるようなのでデバッグに便利そうです。

参考

• amazon web services - How to assume role with the new AWS GO SDK-V2 for cross account access - Stack Overflow
• stscreds package - github.com/aws/aws-sdk-go-v2/credentials/stscreds - Go Packages
• aws package - github.com/aws/aws-sdk-go-v2/aws - Go Packages
• Logging | AWS SDK for Go V2

*1:デフォルトは1時間の有効期限です。

2022年技術系、仕事やったこと

2022年は保守色の強い1年でした。年度はじめからフルリモート勤務(1on1等で月1,2出勤)となり勤務スタイルが大きく変わりました。前から温めていたDB(Aurora)のバージョンアップという重要度と期限がある重大タスクをPJリーダーとして計画通り年末に無事完遂したので、上々の出来だったと思います。アプリケーション的には新規開発を抑えてDBアップグレードをやったんですが、自分はインフラ寄りなので結局新しいことやっててなおかつインフラ的には結構いい経験を積めました。

扱ってるのは引き続きGo、AWS、Terraform、ansibleな感じですが、自分含め生み出してしまった過去の遺物をある程度整理していけました。毎年何やったか忘れてしまうので、サマリだけでも書いておくことに。詳細書けるのはそのうちまとめていきたいところ。

ざっくりサマリ

• Aurora MySQL v1(MySQL5.6互換)からAurora MySQL v2(MySQL5.7互換)へのアップグレード
  • アップグレード方式の調査(2022/11末のre:Inventで発表されたBlue Green Deploymentで自動化されました)
  • 互換性のなくなる挙動の洗い出し、修正内容整理
  • karateを使ったAPIのE2Eテストのベース作成と主担当APIのケース拡充
  • 本番含め全環境アップグレード作業
• その他保守系
  • ansibleのバージョンアップ
  • terraform対応拡充
  • 古のインフラ系を整理、順次縮退
  • ドキュメント整備
  • システム運用系の細いツール実装
• 新規モノ
  • イベント用の短期インフラ整備(GithubActionsでS3デプロイ、CloudFrontでの静的配信)
  • SystemManagerでのport forwarding整備
  • 特定機能群のWebAPI実装(Go)
• 定常タスク
  • サーバサイド全般のアーキテクチャ設計/コードレビュー
  • DBクエリパフォーマンスチューニング
  • リリース作業
  • 各種障害、不具合修正対応
  • 軽微な改善
• OSS系
  • やりきってないけど自分のツールのaws-sdk-go-v2対応
• 個人的興味
  • Cloudflare関連、ZeroTrustとWorkers他
  • Datadog等Observability SaaS

2023年

Aurora v3(MySQL8互換)アップグレードに向けての準備兼サービスのリファクタリング/リアーキテクチャかな。あとは自分のOSS整理とか。