とんちゃんといっしょ

Cloudに関する技術とか日常とかについて書いたり書かなかったり

在宅用に椅子を買う前に

2月からずっと在宅勤務をしているからか肩こりが酷くなってきた。

普段はダイニングテーブルとダイニングチェアで仕事をしているので、椅子を買うべきかも考えたのだが、ダイニングにオフィスチェアやゲーミングチェアはおきたくないなーと思ったので知り合いにおすすめを聞いたところ、姿勢矯正のシート(?)的なのが良いと聞いたので買ってみた。

知り合いに勧められて上記のMTG Style Athlete IIを購入し、1週間使ってみるとたしかに腰とかは楽になった気はする。

しかし肝心の肩こりは多少良くなったような気もするが・・・まだわからん・・・

とりあえずGW開けまで試してみて、在宅勤務がまだまだ続く(とは思うが)ようだったらイスも検討しようと思う。

子供向けレシピ本

最近上の子がこの本を見て料理を作ってくれる。

イラスト多めでわかりやすいし味も美味しい。

ちょっと難しいレシピになると親も手伝わないといけないけど、一緒にやるのは面白いのでそれはそれで楽しいw

個人的にはオムレツやだし巻き卵などの卵周りの料理を適当に作っていたけど、改めてレシピを見ると思った以上にバターや牛乳が使われていたけどいつもより美味しかったので学びだった。

最近は家を出れないことがおおいけど、子供と家で過ごす時間を楽しくできればと思う今日このごろ。

KubernetesのSecret管理周りの雑調べメモ

GitopsでKubernetesのManifestをGit管理しようとした際に、Secretは暗号化されていると言ってもBase64だしどうするんだろうと思って調べた。

結論からいうと、サイボウズさんのブログをみるかぎりKubeCon19でも話題にはなっていたがまだ決定打はない模様(2020/04/06時点)

blog.cybozu.io

しらべたこと

SecretGenerator

現在Kustomizeを使っているのでKustomizeでSecretをどうするのかを調べたところ、 SecretGeneratorという機能があるらしい。

deeeet.com

secretGenerator:
- name: app-tls
  commands:
    tls.crt: "cat secret/tls.cert"
    tls.key: "cat secret/tls.key"
  type: "kubernetes.io/tls"

しかし調べると上記の commands はセキュリティの理由から廃止になったらしい。

github.com

commands is removed from SecretGenerator due to a security concern. One can use files or literals, similar to ConfigMapGenerator, to generate a secret.

現在はfilesやliteralsを使えとのこと。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
secretGenerator:
  # generate a tls Secret
- name: app-tls
  files:
    - secret/tls.cert
    - secret/tls.key
  type: "kubernetes.io/tls"
- name: env_file_secret
  # env is a path to a file to read lines of key=val
  # you can only specify one env file per secret.
  env: env.txt
  type: Opaque

しかしSecretGeneratorは結局のところ指定したファイルや環境変数などをBase64エンコードしたSecretをKustomizeが生成してくれるだけなので、 SecretのGit管理という意味では意味をなさない。

GCPの場合

GCPで完結させるなら割とシンプルにできるっぽい。

  1. Cloud KMSで鍵を作る
  2. Cloud KMSで作った鍵を使ってデータを暗号化
  3. レポジトリに暗号化したデータをコミットしてPush
  4. Cloud Buildの実行(復号とデプロイ)

qiita.com

Secretとして使うファイルは復号してたあとCloud Buildの中の環境変数として取り込むっぽい

cloud.google.com

まだ調べきれてないやつ

SealedSecret

github.com

Kamus

github.com

Helm-secrets(Sopsというのを使うらしい)

qiita.com

色々ありすぎてまだ調べきれてないので途中までですがなんかの参考になればいいな・・・

Tech Nightっていうイベントで「保育園にChaos Engineeringを提案した話」をしてきた

会社で不定期にTech Nightという有志の勉強会があったのだが、 最近の新型コロナウィルスの影響で、オフラインでのイベントが難しくなったのでリモート開催されることに。

今回ノリで発表することにしたのだが、最近やってるGitOpsの話をするか、 以前にQiitaに書いた保育園にChaos Engineeringを提案した話をするか悩んで、後者にしました。

qiita.com

悩んだのにもいくつか理由があって、GitOpsの話も知ってもらいたいなーと言う思いがあったのですが、 Chaos Engineeringを通して学びを得ることやナレッジを共有することができるっていうのを、 会社の人達に知ってもらいたいなとおもって決めました。

資料はこちらです

speakerdeck.com

当日はリモートでの発表だったのでインシデント被害者である下の子にも画面に登場してもらいましたw

初めてのリモート発表だったのですが、人が前にいないので気楽な反面、反応がないので一方的にしゃべる感じになってちょっと難しかったです。

発表が終わったあとお酒を飲もうとしたら、下の子に「パパとねんねするの!」とベッドに連れ込まれ、発表を一つ聞き逃しましたが、 寝かせつけたあと、上の子のお弁当の仕込みをしながら発表を聞いたり、お酒を飲みながら議論に参加したりととても楽しかったです。

飛び込みの発表者が現れたり、議論が盛り上がったので、22時から始めて1時半頃までイベントをやってました。

オンラインの勉強会は自由度が高く面白かったので皆さんも参加する機会があればぜひ参加してみてください!

markdown-pdfを使おうとしてハマったので解決した話

MarkdownファイルをPDFに変換したくて調べていたところ、markdown-pdfというツールを見つけたんで試してみたら動かなかったので解決した話。

github.com

READMEに従ってnpmでインストール。

% npm install -g markdown-pdf --ignore-scripts

実行

% markdown-pdf sample.md
internal/validators.js:112
    throw new ERR_INVALID_ARG_TYPE(name, 'string', value);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "file" argument must be of type string. Received type object
    at validateString (internal/validators.js:112:11)
    at normalizeSpawnArguments (child_process.js:398:3)
    at spawn (child_process.js:534:16)
    at Object.execFile (child_process.js:224:17)
    at WriteStream.<anonymous> (/usr/local/lib/node_modules/markdown-pdf/index.js:117:22)
    at WriteStream.emit (events.js:208:15)
    at finishMaybe (_stream_writable.js:645:14)
    at _stream_writable.js:623:5
    at WriteStream._final (internal/fs/streams.js:280:3)
    at callFinal (_stream_writable.js:616:10)

エラーやんけw

自分のmdファイルが悪いのかなと思ったりもしたが、ぐぐってみるとこんなIssueを発見

github.com

どうもインストールの際の --ignore-scripts オプションを外すと動くらしいのでアンインストールるして再インストールする

% npm remove -g markdown-pdf
removed 106 packages in 1.09s
% npm install -g markdown-pdf
...
+ markdown-pdf@10.0.0
added 106 packages from 388 contributors in 13.028s

再度実行するとエラーなくpdfファイルができていた

% markdown-pdf sample.md
% ls
sample.md         sample.pdf

これREADME変更したほうが良いのでは・・・

Gitlab CIで長いScriptを複数行に分けて動かす

Packerのイメージ作成を自動化しようとしてGitlabのCIを触っていて、パラメータなどを渡すので長いScriptを複数行に分けたいと思ったので調べた。

当初 - を並べてみたのだがそれではうまく行かなかった。

build:
  script:
    - packer validate
    - -var project_id=$PROJECT_ID
    - -var image_name=test-$CI_JOB_ID
    - -var image_family=gitlab
    - -var image_zone=$IMAGE_ZONE
    - packer.json

調べたら次のStackoverflowがヒットしたので - を消してスペースで対応。

stackoverflow.com

build:
  script:
    - packer validate
      -var project_id=$PROJECT_ID
      -var image_name=nginx-$CI_JOB_ID
      -var image_family=gitlab
      -var image_zone=$IMAGE_ZONE
      packer.json

これで動いたのでヨシ!

メールアドレスは個人情報に含まれるのか

以前友人たちとメールアドレスが個人情報に含まれるのかという話をして、調べ物をしたのを思い出したのでまとめておく。

個人情報とは

まずそもそも個人情報とは何なのかを調べると以下のサイトでは

生存する個人に関する情報であって、特定の個人を識別できるもの

だそうで。

www.gov-online.go.jp

この書き方はいくつか気になることがあるのでそれも含めてついでに調べていく。

生存する個人に関する情報

これについては総務省のページにそのものの答えが書いてあった。

www.soumu.go.jp

Q3-1
保護法で規定している「個人情報」とはどのようなものですか。例えば、次のような情報は、「個人情報」に当たりますか。
 1) 死者に関する情報

(中略)

 保護法上、「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名等により特定の個人を識別することができるものをいいます(第2条第2項)。
 1)については、生存する個人に関する情報でないことから、一般的には、個人情報に当たりません。しかし、死者に関する情報であっても、当該情報が遺族等の生存する個人に関する情報でもある場合には、生存する個人を本人とする情報として、個人情報に当たることになります。例えば、死者に関する情報である相続財産等に関する情報の中に遺族(相続人)の氏名の記載があるなど、遺族を識別することができる場合には、当該情報は、死者に関する情報であると同時に、遺族に関する情報でもあります。

死者に関するもの(!生存する個人のもの)は個人情報にあたらないけど、遺族に関する情報がある場合個人情報に当たることになるということらしい(ex. 相続財産等に関する情報)

メールアドレスは個人情報に含まれるのか

で、本題のメールアドレスについてなのだが、これについても上記の総務省のページと同じところに答えが書かれていた

Q3-2
メールアドレスは、個人情報に該当しますか。
A
 保護法では「個人情報」を、「生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの」と規定しています(第2条第2項)。
 メールアドレスには、個人情報に該当するものとしないものがあります。記号を羅列したもの(例えば「0123ABCD@soumu.go.jp」)のように、それだけでは特定の個人を識別できない場合には、個人情報には該当しません。しかし、特定の個人の氏名を記載したもの(例えば「〔氏名のローマ字記述〕@soumu.go.jp」)のように、特定の個人を識別できる場合には、個人情報に該当します。
 なお、保護法では、「他の情報と照合することができ、それにより特定の個人を識別できることとなるもの」(第2条第2項)も個人情報としています。このため、記号を羅列したメールアドレスであったとしても、例えば、それがある省のある職員のメールアドレスであって、当該省の職員であれば職員名簿等により誰のメールアドレスなのか分かるような場合には、そのようなメールアドレスは、個人情報であるといえます。
 ただし、メールアドレスから直ちに特定の個人を識別することが難しい場合であっても、メールアドレスは、各個人にとって私信を受け取るなどのためのインターネット上の住所とも言うべきものであり、慎重かつ適正に取り扱う必要があることに変わりはありません。

いろいろ書かれているがまとめると

  • 特定の個人の氏名を記載したもののように、特定の個人を識別できる場合には、個人情報に該当する
  • メールアドレスが記号の羅列の場合
    • メールアドレスから所属がわかり、かつ、その所属組織の誰もが名簿等の何らかの手段により誰か判別が可能場合は個人情報に該当する
    • メールアドレスから所属はわかるが何らかの手段を用いても個人の判別ができない場合は個人情報に該当しない
    • メールアドレスから所属がわからない場合は個人情報に該当しない

Gmailのように個人で利用可能なフリーメールだと個人情報に該当しない可能性はあるものの、 企業に所属する人のメールアドレスはドメインから所属がわかる事が多いのでほぼ個人情報と思っていいという話っぽい。

結論

メールアドレスも場合によっては個人情報にあたるので漏洩には気をつけましょう。

追記(2020/2/21)

自治体によっては故人の情報も保護されるところがあるらしい。