KindleのアプリのUI悪い部分
概要
Kindleのアプリの体験が率直にいうと最悪なことはよく知られたことだが（ここで要出典と書こうとしたが「Kindle 使いにくい」をTwitterで検索するとたくさん出てくるのでここでは周知の事実として扱うものとする）
あまり言語化されていないようなので書く
一度読んだ本を最初のページから開くことができない
基本的に一度開いた本は読んだ途中のページから開かれる。それは当然いい機能だとは思うんだけど、ワンアクションで最初から開くことが何故できないのか疑問
読み終えた本、おそらく最終ページまで行った本は既読マーク（スクショで囲った部分）がつく
最後まで読んだという判定がありながら、本を開いた際に奥付けが表示されてユーザーが満足に思うと考えているのだろうか
ちなみに「未読にする」ボタンを押すと既読判定が消えるだけで開いた瞬間に既読になる、ジョークボタンか？
サマルとこれに関しては２点課題がある
- ワンアクションで用意されていない
- 最終ページまで行った本に対してのケアがない
しおり機能の誤判定が多い
スクショの赤線で囲ったあたりをタップすると、しおりを挟む機能がある
タップする、と簡単に言ったが再現性が非常に低く、おそらく画面とベゼルのぎりぎりのところをタップするとしおり機能が発動する、指が完全に画面内に入っていると駄目
ちなみに画面内をタップすると上のように「なんか色々できる画面」になる
実はしおり機能を使っていなんで、私の場合画面をタップする場合は100%２番目の画面になってほしいが結構な確率でこの「しおり」が発動する。
そしてしおりの解除がしたくてもう一度タップすると今度は２番目の画面になる
最悪だ...最悪ランキングの上位最悪体験である
別にしおり機能があることはいい、使う人もいるんだろう
この判定のピーキーさは本当にやばい、使ったら絶対わかる
絶対なんかあったはずで、しおり機能は例えば長押しするとか（現状長押しには何も割り当てられていない）、設定でしおり機能をオフにできるとか
表紙に戻るためのアクションが長い
「表紙に戻る」という行為はほんの一覧ページからできて然るべき、と言った内容は既に書いたが、実は本を開いている最中でさえ１アクションどころか３アクションかかる
スクショで示したように
- 画面の真ん中をタップする
- ハンバーガー亜種アイコンをタップする
- 表紙をタップする
の３手順かかる
さらに最悪ケースとして、稀に目次が細かく別れている本があるのだが、その本の場合「表紙」が出てくるまでスクロールする必要がある
必要なアクション数が多いことは最悪さの権現であるが、実は上記のフローに隠れ最悪UIが潜んでいる
それは２と３の距離が遠いということである
それだけ？と思うかもしれないが、やったらわかる、やってみなはれ鳥井信治郎
画面のアスペ比からわかると思うがこれはiPadであり（厳密には10.9inch のAir）私の指は11inchもないので片手で支えてもう片方で操作する
つまり２をタップする際に左手の指を使っているのだが（私の左手は左についている）、右手はiPadを支える状態になっていて右手は操作できない（しにくい）
なので３をタップする際にはiPadを持ち替えて右手でタップすることになる。わからん人間は仰向けになって寝ながら漫画読んでいる時を想像してくれ
あと、片手で全て操作したらいいのでは？って人間、買え！iPadを、でかいから
コレ、本当に最悪なんでこのデザインに決定した人のマウスを逆の手でしかクリックできないようにしてほしいし、実はちょっと前まで３のボタンが実は左にあったんでデザイン戻してほしい、切実に
サマリ
どこら辺にボタンがあると快適なのかを考えられてないなぁと感じるアプリは多い
私もiPadをポートレートモードで持つこともあるし最強のボタン配置はないと思う
ただ、一部のゲームはボタン配置をいじれるようになっていて流石に体験がいいなってなる
あと、Desktop Webも同じ課題に向き合わなければならない
ちょっとした操作をするたびにポインタを左右に振らされるとゲンナリするし、その操作を何回もしなければいけない時には鬱になる、FPSじゃないんですよ
考えた結果それでも操作の距離が遠くなる場合、視線とポインタの位置を一致させる人が多いように感じるので、視線誘導を意識しながら配置すると良いと考えている
GitHubでrepositoryごとに権限が割り当ててある人間を探す
abst
GitHubの権限を真面目に管理することを考えると、やはりrepositoryに対してUserを紐付けることをやめたい。 つまりRepositoryに対してTeamを紐づける権限管理をやりたい。
しかし、Repositoryを作ったUserがadminとして設定されてしまう仕様や過去に適当に割り当ててしまっていた経緯から、いまだにRepositoryに対して割り当てられているUserを探して削除する必要がある。
今回はGitHubのGraphQL APIを用いて上記のようなRepositoryを探す
実装手法
以下のようなQueryにした。ORG_NAMEを書き換えること
query FindRepo($node_id: String) { organization(login: "ORG_NAME") { repositories(first: 20, after: $node_id) { totalCount pageInfo { endCursor hasNextPage } nodes { id name nameWithOwner collaborators(affiliation: DIRECT) { edges { node { login } permission permissionSources { source { __typename ... on Organization { login } ... on Repository { nameWithOwner } ... on Team { slug } } } } } } } } }
依存関係として、jq,ghが必要
TMP_FILE="$PWD/tmp.json" DEST="$PWD/repo_list" QUERY="$PWD/repo.graphql" set -ex gh api graphql -f query="$(cat $QUERY)" > $TMP_FILE jq -r '.data.organization.repositories.nodes[]|select(.collaborators.edges|length > 0)|.nameWithOwner' < $TMP_FILE > $DEST cat $TMP_FILE while [ "$(jq -r '.data.organization.repositories.pageInfo.hasNextPage' < $TMP_FILE )" == "true" ]; do sleep 1 cursor=$(jq -r '.data.organization.repositories.pageInfo.endCursor' < $TMP_FILE ) gh api graphql -F node_id="$cursor" -f query="$(cat $QUERY)" > $TMP_FILE jq -r '.data.organization.repositories.nodes[]|select(.collaborators.edges|length > 0)|.nameWithOwner' < $TMP_FILE >> $DEST cat $TMP_FILE done
解説
Repository の affiliation: DIRECT にするとRepositoryに対してUserが紐づいた人が出てくる.
All collaborators with permissions to an organization-owned subject, regardless of organization membership status.
らしい
bashで雑にloopを回していく。
権限を取り除く
API経由でできなくもなさそうだが手で取り除いた。
正直、このコードはひどいな、と思いつつ...
for i in $(cat $DEST);do echo $i; sleep 2;done|xargs -n 1 -I @ open https://github.com/@/settings/access
ブログなどのコードはメンテされないので別のとこで面倒を見るためのリンク
財テク
このテーマ考えたの自分だけど、そんなに自分は資産運用に関してよく考えてないことに気づいた&そんなに資産がない
資産状況
NISA口座を開設した
この行動するまでに1年ぐらいかかった。しかしNISAは開設して終わりではない。入金して投資しなければいけない
今年中に終わることができるのだろうか
IDECO資料請求した
でも60歳まで引き落とせないのリスク高すぎるのでは？ってなって辞めた。
この制度、新卒で入った会社にずっといるタイプの人間じゃないと性格的に恩恵感じないのでは？それか個人事業主系の人
そもそも60歳って微妙すぎる。45歳ぐらいでFiredしたい人間には向いてない。制度として定年宣言をした段階で貰える&再加入不可でよくないか？
詳しくないので上のwazapもできるのかもしれない
Folio
folioやってる。130万ぐらい、そのうちロボアドが80万ぐらい。
NISAでやれって言われたらまぁそうってなる。
ふるさと納税
12月18日、ついにやった。
前はさとふるを使っていたが、ソフトバンク系のサービスは全て使わないようにしているんで辞めた。
生活費運用
私名義の共同の口座に定額入れる仕組みで運用している。家賃などはそこから落ちる。 あと B/43 | ラクして予算管理！家計簿プリカというサービスを使っている。共有のクレカが使える的なやつで、これはかなりベンチ
ついでに招待コード貼っておきます W4QDTL
もともと上記の共同の口座のキャッシュカードについているデビットカードで運用していたが不便だった。
B/43の不便点としては、スマホ決済対応してないのがある。
もともとKyashはQuickPayが使えて最近共有カードの概念を出してきたので、B/43も対応するんじゃないんですかね、知らんけど。
ちなみにKyashは初期使っていたけど、共有カードの概念がないのと資金決済法対応でサービスがガラッと変わったのでちょっと前に解約した。 まぁ色々察するところもあってしょうがないとは思うけど、便利な機能で客寄せしてコアバリューをガラッと変えてくる企業は私のポリシー的に使うことができない。
理想の働き方について
共著ブログ私信電信、今回のテーマは「理想の働き方」
理想の働き方と聞いて、働く上での姿勢と作業環境の２点が思い浮かんだ
働く上で大事にすること
¬ 友情・努力・勝利
これは解説すると「{信用,信頼} しない」「努力と感じることをしない」「終わりがない」と言う話
{信用,信頼} しない
一つ目は言葉通りだが、例えば
- システムを組む上で人間を使う限りはミスや悪意を受容する。
- 実績や過去の功績でコードやアーキテクチャに関する評価を決めない。
- 自分が書いたコードはバグなく動くという誤った認知を持たない。
Trust But Verifyが言葉として近いかもしれない
ちなみに「信用と信頼は違ってTrustは信頼で〜」みたいなこと言うてる人間よくおるけど、日本にそんな文化存在せんから嘘やとおもてる。あるのは誰が腹を切るか決める文化だけ。まぁもっと最悪なのは腹切ることを責任と勘違いしている人間。
努力と感じることをしない
二つ目は、個人と仕事の話があって意味が若干違う。
個人の話は学習順序かな
たいして興味ないことに対して義務感で勉強するのはやめたほうが良い。精神に悪いし身につかない。 当然なんでも知っているに越したことはないが、興味が湧かない理由の一つに学習する上での前提として必要な経験や知識がまだ自分に足りていないんだな、と思っている。 そもそもその分野に興味がないなら時間は有限なので辞める。
仕事の話は、姿勢というか心掛けで
単に業務上必要な学習はコードを書く時間と比べてなんら変わらないただの"仕事"なので、いちいち努力と分けて考えない。
そもそも努力っていう言葉自体が僕自身の中で「行動の意図を理解しないまま頑張る」みたいな意味になってるかもしれん。
終わりがない
これはソフトウェア開発サイクルに終わりはないのでExitしようが開発は続く。"終わり"を前提としたソフトウェア開発は"終わり"より早く破綻する。
「これ、ちょっとの間しか使わないんで適当で」って作られたJobはそれが災厄を引き起こすまで動き続けるし、仮説検証のためのプロトタイプは大体書き直されることはない。
「だからちゃんと設計しよう」ではなくて「後悔しない意思決定にしとこう」みたいな話、終わりはないので。
「他に得意な言語はあるけど、聞いた感じ開発早そうなんでRailsで！これが適材適所！」
正気か？
作業の環境
音楽がかかっていると良い。「アトモスフィア；かかっている」が大事で自分でセレクトした曲が流れるのは好きじゃない。 音楽がかかっていないと？なんか気が散る感じがする。他人の気配とか話し声とか。 そもそも気は散るものなので散る対象が音楽に限定されるのが良いんかもしれない
歩き回れる方が良い。 癖かもしれないし慣れかもしれないが、思考と体の動きが動きが相関している気がする。
椅子はいい方がいい。今年に入ってherman millerのエンボディを買ったがかなり良かった。 ただ自宅がカフェとかに比べてひらけてない（＝オープンでない＝Not 鴨吻）ので、そこは不満
猫。 猫はストレスを極めて減らしてくれるが、仕事中に構って欲しがってくるので集中できない。危険
安易なSaaSのユーザー数課金は体験が最悪
サマリ
- ユーザー数が増加しても、顧客の感じる価値が線形に増えない。
- Entityに対して情報が公開されている範囲の制限できる場合、一部のユーザーはほとんど価値を感じていないが課金されている状態になる。
- 全体のリソースはユーザー数に対して時間で積分した量になるので、ユーザー数が増えれば増えるほど価値を感じていない人間が増える。
ユーザー数課金をしているいい例
Slack
馬鹿みたいにprivate channelを作る会社でなければ、一人のユーザーに対して情報が制約されている状態にはほぼならない。 そもそも、一人の人間のとりうるコミュニケーション量は上限がある（と思われる）ので、でかい企業と小さい企業で一人のユーザーが体験する価値は（多分）変わらない。 また、guest などの機能はまともに使っていると実質無料でついてくる。
KING OF TIME
理由：(略）
これは労務管理している側と勤怠つけるだけ側に分かれるので、admin側ユーザ課金+一般ユーザー課金でもいいと思ったがユーザ課金だけらしい。
微妙な例
Google Worksapce
機能が多いのはいいことだが、会社全体でHardUseしていない場合、例えばインターン生のメールアドレスだけ発行したい場合などに高いなと感じる。
Entityに対して情報が公開されている範囲の制限できる場合、一部のユーザーはほとんど価値を感じていないが課金されている状態になる。
悪い例
読者（およびサービスプロバイダ）の課題とする
後書き
ビジネスの話はしていない。課金に対する体験の話をしている。 金を払うという行為は納得していないと体験として悪いと考えている。 例えば、時価で提供している飲食店もそうで注文した際に金額がわかっていればその時点でまずかろうが金を払うことに納得はしているが、後から金額がわかることは微妙と考える（特に美味しくなかった場合）。
最近おもしろかった漫画( 7月~)
これは何？
概要
ざっくり7月〜で読んだ本、一旦書き出して振り返ってみる Primeの特典とかkindle unlimitedで読んだ本で特に印象に残らなかったものは省いている
八百森のエリー 1~5
野菜市場の仲卸の漫画、仲卸って流通の間に挟まっているなにか 、みたいな認識だったけど色々やってるんだなぁみたいな気持ちになった。 野菜界における「重版出来」的ポジションの漫画、雑誌移転により一瞬止まっていたぽい
ブラック・ラグーン（１２）
最初に読んだのは高校生の頃だろうか、久々に新刊が出て懐かしい気持ちになった。 "ブラック・ラグーン"であることに間違いはないが、なんか雰囲気が変わったというか馴染みの定食屋でいつも頼むメニュー的な？。作品の年齢より作者の年齢の方が早く進みますからね... BUMP OF CHICKENで言うとユグドラシル以降という感じ。
山賊ダイアリー
一度猟に行って見たいなぁと思ってはいるが銃の免許をとるのは（面倒さの）ハードルが高い 脱サラして猟師なった人のエッセー的な漫画なのでイメージがつきやすくて良いね
来世ではちゃんとします 7
あずまんが形式の（今時４コマで話が進むのが当たり前なので今更こういう言い方はしないのだろうか？）"""現代的な価値観の"""恋愛漫画 登場人物は多いが話が独立しているので読みやすい
クマ撃ちの女
なんかちょっとDirtyな部分も描かれているが、実態はもっとDirtyなのかもしれない。 取材漫画的な感じだけど、どこまで事実なんだろう
ランウェイで笑って（２２）
完結しちゃいましたねぇ(ﾆﾁｬｧ（略 カエルDXの絵
よかったですね
違国日記
普通の（ここでの普通さとは社会性の高い人間が自己を正当化する上で使うもの）女子高生が、非健常者の（ここでの健常者は自己の健常さを自己の定義する健常性から定義するもの）家で、"""コミュニケーションの仕方"""を学ぶ
これは結構良くて〜なんか距離感的な〜（言語野が壊れた）
東京入星管理局
設定が飛ばしすぎてて難しいけど、スピード感ある
サイバネ飯
上と同じ作者、こっちの方が好き
読切いろいろ
山本先生いいですね〜
昭和元禄落語心中
シュッと読む分には面白いが、が、作者の嗜好との違いによる引っ掛かりが。ネタバレになるんで書かないが、「腐系の方ってこういうことするよね〜〜？？」ってなるアレ。わかりますよね？
メイドインアビス（１０）
新刊が1年ペースなので、また1年待たねばならんのか... 出てくるキャラクターが可愛いので好きです。あと作者とのシナジーがある。
JKハルは異世界で娼婦になった
異世界転生俺TUEEメタ作品、テーマであるところの娼婦が生かせてないように感じた。倉科遼っぽく書いてもウケないのはわかるが。
Artiste
いい人が出てくるいい話、料理漫画ではない、好き
衛府の七忍
誤チェストでごわす、の本
１０巻読んでもどういう世界観なのかわからない
この世界は不完全すぎる（４）
SAOの世界でデバッガが閉じ込められてしまいました、みたいな話。 職業柄、親近感があるのでいいですね
葬送のフリーレン（５）
この漫画読んで最初に思ったこととして「こういう叙事詩？的な漫画って増えてる感じするよな〜メタが進んでる的な〜」 今の時代に物語を描きたくても例えばタイの大冒険みたいに「魔王を倒す過程を描きます」を描いてもウケないのはわかる。 傘でアバンストラッシュしたよね？みたいな前提で話を作ってるよね。
AV男優はじめました
そもそも自分は業界の話みたいなのが好きなんすよね〜 映像作品とかだとドキュメンタリしか見ないし、その中で汁男優からAV男優やります！っていうのは新しいかなって
BEASTARS ２２
なんかこういう設定の作品って多いよね？共存できない存在が頑張って共栄する的な
この作中でいう草食動物や肉食動物は我々の世界でいうソレらと実は違ってメタファー的な存在なんだけど、現実世界の存在とメタファー存在の境界を曖昧にぼかしていることにより作品への没頭感というか親しみやすさを与えているのがすげーうまいなって思った。 作者の性癖が強く出ているが、その点も曖昧にしちゃってるんで凄いですね、パワープレイしていますね。
抜刀（１）
なんか荒いけど攻めてて面白いが次の巻は買う決断に至らなかった、続きが気になるかというと？
運用中のS3を暗号化する話
概要
"""社会"""にはいろいろあるので、運用中のS3を暗号化しました
HERPの話です。採用してます。
ざっくり以下の内容（+ S3 Bucket Key）をやった、という感じです
Encrypting objects with Amazon S3 Batch Operations | AWS Storage Blog
制約と方向性
ここでいう暗号化はSSE(Server Side Encryption)です
S3の暗号化はオブジェクトごとなので、暗号化済みオブジェクトとそうでないものが混ざったBucketに対して権限さえ適切であれば問題なくR/Wすることができます。
ちなみに鍵の指定方法として
がありますが、今回はカスタマー管理のCMKにすることにしました。SSE-KMSです。
カスタマー管理のCMKはクロスアカウントできるとか、キーロテーションの期間を変更することができるとかのメリットがあります。
なので、今回の適切な権限はアプリケーション側が使用している権限に以下が追加されることを想定しています
{ "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Effect": "Allow", "Resource": [ "なんか鍵" ] }
2020年ごろに S3 バケットキーという感じの機能が追加されて、R/WのたびにKMS使用コストがかかっていたのが不要になるのでそっちを使います
Amazon S3 バケットキーを使用した SSE-KMS のコストの削減 - Amazon Simple Storage Service
KMS キーポリシーが適切なPrincipalに対して kms:Decrypt が許可されているのを確認します。クロスアカウントでなければ問題ないはずです。
余談ですが、Principalが s3.amazonaws.com でなくていいんすね。ここら辺のPrincipal感覚はあまりわかっていないですね。
フロー
というわけで、以下のフローでやります
アプリケーションに上記の権限を足して、デプロイする
BucketのSSEを有効にする
暗号化されていないものを暗号化する
BucketのSSEを有効化
terraformの擬似コードですが、以下のようになります
resource "aws_kms_key" "this" { }
resource "aws_s3_bucket" "this" {
bucket = "example"
server_side_encryption_configuration {
rule {
apply_server_side_encryption_by_default {
kms_master_key_id = aws_kms_key.this.arn
sse_algorithm = "aws:kms"
}
bucket_key_enabled = true
}
}
versioning {
enabled = true
}
}
暗号化されていないものを暗号化する
Objectを再Putすると暗号化されます。 最近はs3 batchと呼ばれる便利なものがあるのでそれを使います
inventory 設定
s3 batchを実行するためにkeyのリストが必要なので s3 inventoryを使います。
s3 inventoryの実行結果を保存するBucketを用意します。
resource "aws_s3_bucket" "s3-batch" {
bucket = "example-s3-batch"
force_destroy = true
policy = <<EOF
{
"Version":"2012-10-17",
"Statement":[
{
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": [
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::example-s3-batch/*"
],
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:::*"
},
"StringEquals": {
"aws:SourceAccount": "${アカウントID}",
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}
EOF
}
s3 inventoryの設定は以下のようになります
resource "aws_s3_bucket_inventory" "auth" {
bucket = aws_s3_bucket.this.bucket
name = "exapmle"
included_object_versions = "All"
optional_fields = ["EncryptionStatus"]//, "BucketKeyStatus"
schedule {
frequency = "Daily"
}
destination {
bucket {
format = "CSV"
bucket_arn = "arn:aws:s3:::example-s3-batch"
}
}
}
このコメントアウトされているBucketKeyStatus部分はBucket Keyで暗号化されているかのステータスが取れるので本当は欲しいんですが、terraformのaws providerで対応されていないのでterraformでやりたければ諦める必要があります。（今週末時間があれば修正したいな...）
inventory結果
24~48時間程度たつと、結果がexample-s3-batchに保存され始めます。 Dailyでどのタイミングのリストかわからないので、余裕を持つ必要があります。 X日にSSEを有効にしていた場合、X+2日の日付のを使うぐらいがいいんじゃないでしょうか。
s3 batch
s3 batch実行用のRoleを作ります
Granting permissions for Amazon S3 Batch Operations - Amazon Simple Storage Service
上を参考にしますが、ブログ用に書き直すがめんどくさかったので、サンプルのコードではs3の任意actionを許可しました。 kmsの権限を足すことを忘れないように
resource "aws_iam_role" "s3-batch" {
name = "s3-batch"
assume_role_policy = <<EOF
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":"batchoperations.s3.amazonaws.com"
},
"Action":"sts:AssumeRole"
}
]
}
EOF
}
resource "aws_iam_role_policy" "s3-batch" {
policy = <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:*"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::*"
},
{
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Effect": "Allow",
"Resource": [
"*"
]
},
]
}
EOF
role = aws_iam_role.s3-batch.id
}
実行していきます。s3 inventoryから出力されたcsvからs3 batchを積むスクリプトが以下になります。適宜環境変数は埋めましょう。 わかりにくいですが、envはs3 inventoryのname属性になります。
manifest_bucket=
env=
target_bucket=
date=
# manifest.jsonにcsvのpathが入っている
target_bucket_arn=arn:aws:s3:::$target_bucket
key=$(aws s3 cp s3://$manifest_bucket/$target_bucket/$env/$date/manifest.json - | \
jq -r '.files[].key')
# Amazon S3 Selectを使って暗号化されていないobjectのpathだけ取得する
# s._4が isLatest s._6がEncryptionStatus
aws s3api select-object-content \
--bucket "$manifest_bucket" --key "$key" \
--input-serialization 'CSV={},CompressionType=GZIP' \
--output-serialization 'CSV={}'\
--expression "select s._1, s._2 from s3object s where s._4 = 'true' and s._6 = 'NOT-SSE'" \
--expression-type SQL $env-output.csv
csv_key=$env/output.csv
# なんかs3に上がってないとダメなんでアップロードする
aws s3 cp $env-output.csv s3://$manifest_bucket/$csv_key
etag=$(aws s3api head-object --bucket $manifest_bucket --key $csv_key | jq -r .ETag)
# s3 batchのJobを積む
aws s3control create-job \
--region ap-northeast-1 \
--account-id "$AWS_ACCOUNT_ID" \
--operation "S3PutObjectCopy={BucketKeyEnabled=true,TargetResource=$target_bucket_arn}" \
--manifest '{"Spec":{"Format":"S3BatchOperations_CSV_20180820","Fields":["Bucket", "Key"]},"Location":{"ObjectArn":"arn:aws:s3:::'$manifest_bucket/$csv_key'","ETag":'$etag'}}' \
--report "Bucket=arn:aws:s3:::$manifest_bucket,Prefix=s3-batch-reports,Format=Report_CSV_20180820,Enabled=true,ReportScope=FailedTasksOnly" \
--priority 42 \
--role-arn "$ROLE_ARN" \
--client-request-token $(uuidgen) \
--description "$env" \
--no-confirmation-required
operationのoptionに BucketKeyEnabled=true が含まれているんですが、S3 Bucket Keyが有効である場合このオプションなしで動くと思っていたんですが、つけないとダメでした。
このオプションなしだとS3 Bucket Keyなしで暗号化されます。
最初、kms のkey policyのPrincipalにs3 batchが含まれていないことが原因かと思ったのですが、そこそこ試した結果kmsのkey policyは関係ないと判断しました。
確認
暗号化されているか確認するために後日再びS3 Selectを使って確認します
select s._1, s._2 from s3object s where s._4 = 'true' and s._6 = 'NOT-SSE' の結果が空であれば全ての暗号化が完了しています。
現状Objectを上書きする運用をしていないので、今回s._4を見る必要がない気はします。
BucketKeyStatus を有効にしてあれば、s._7 も確認すると S3 Bucket Keyが使われているか確認することができます。
再掲
上記の内容はConsoleをぽちぽちしていてもできると思いますが、HERPでは仕事の完了の定義の中にコード化することを含めています。
