1Password に保存しているクレデンシャルを環境変数として利用するためのツールを作った

私はパスワードやトークンなどを 1Password に保存しています。これらを環境変数として利用したい場合、クリップボードにコピーして set か export して環境変数にセットするか、頻繁に利用するものであれば envchain を利用していました。 envchain はとても便利なのですが、私は Mac と Linux、それから Windows もたまに使っているため、 keychain や Gnome Keyring でそれぞれ保存するのが手間に思っていました。どうせ 1Password に保存しているので、そこから取得してしまえば良いと思い、 openv というツールを作りました。 https://github.com/mrtc0/openv 1Password は公式で op という CLI ツールを配布しています。 CLI ツールがあるということは Web API があるのでしょうが、API へのエンドポイントは公式には提供されていないため、 openv ではこのop コマンドを内部で実行するようにしています。 やっていることは単純なので jq を駆使してシェルスクリプトで同等のことは実現できますが、 op コマンド単体では少し扱いにくいクレデンシャルの追加なども、より簡単に行えるように、一つのツールとして作りました。 年末に少し Rust を勉強していたのもあり、せっかくなので Rust で書いてみました。 Rust のお作法について曖昧なところがあるのでそこは目をつむってください。 使い方 op コマンドが必要になるので https://support.1password.com/command-line-getting-started/ を見てインストールして Sign in します。 このとき eval (op signin my) のように実行して OP_SESSION_* 環境変数をセットすることで、このセッションが切れるまではパスワードを入力することなくログインすることが可能になります。

2020年の振り返りや買って良かったものなど

仕事 会社がフルリモートになった。学生時代に2年ほどフルリモートでアルバイトを経験していたので、そこまで苦ではないと思っていたが、仕事以外でも気軽に外に出ることができないので、意外としんどい。なので意識的に運動をするようにしていた。 あと、リビングに机置いてフルリモートするのが、だいぶ厳しいということが分かったので、来年の契約切れるタイミングで引っ越しして作業部屋を作るぞ。 さて、技術面に関しては Kubernetes, Wazuh と戯れていた一年だった。また、AWS 周りのキャッチアップができた年でもあった。 ペパボではプライベートクラウドを運用していて、自分が普段触っている範囲もその基盤上なので、AWS / GCP などに触れる機会が少なかったのだが、今年は AWS の各種セキュリティサービスや ECS などを触る機会が少しだけあった。 クラウドプロバイダーが提供しているセキュリティサービスやそこで不足しているものを、組織の文化や技術に合う形で、自社の開発、インフラ環境にセキュリティ基盤として実装していくのは面白いと思う。 で、良い成果出したんですか?と言われると、どうなんでしょうねぇ。引き続き頑張りましょう。 OSS リストにしてみたが、こう見ると質も量も全然だなぁ…。何か困ったら自分で作る or 直すマインドでやっているが、その割にこの量なので、新しい領域に取り組んでいないということかもしれない…。 cxray https://github.com/mrtc0/cxray dependency-track-client https://github.com/mrtc0/dependency-tracker-client kubectl-multi-exec https://github.com/mrtc0/kubectl-multi-exec fish-multipass-completions https://github.com/mrtc0/fish-multipass-completions kubectf https://github.com/mrtc0/kubectf container-security-book https://github.com/mrtc0/container-security-book wazuh-ruby-client https://github.com/mrtc0/wazuh-ruby-client github-app-installer https://github.com/mrtc0/github-app-installer Contribution https://github.com/pyama86/google-web-oauth/pull/4 https://github.com/pyama86/oauth-proxy-cookbook/pull/1 https://github.com/evryfs/helm-charts/pull/10 https://github.com/sentry-kubernetes/charts/pull/125 https://github.com/securego/gosec/pull/539 https://github.com/shimoju/metabase-ruby/pull/66 登壇 / 発表スライドなど GMO ペパボ 新卒研修 / Web セキュリティ研修 社内の新卒研修を担当した。詳しくは https://tech.pepabo.com/2020/09/09/newbie-training-2020/ を参照してください。 InfraStudy #6 / インフラ基盤技術のセキュリティとこれから matsumotory さんからお声がけいただき、コンテナ、Kubernetes のセキュリティについて話した。動画が YouTube に上がっているのだけど、たとえ1つ2つでも低評価つくと悲しい…。 YouTuber の皆さんは鋼メンタルだ…。

Kubernetes のセキュリティを学べる kubectf を作った

この記事は GMO ペパボエンジニア Advent Calendar 2020 の12日目の記事です。 昨日は @takutaka さんの 「Kubernetes Custom Controller を手抜きで作る技術」でした。 CRD や Custom Controller を作る際に役立つ情報が載っていて良い記事ですね。 さて、最近私は Open Policy Agent を触ることが多いので、それについて書こうと思っていたのですが、せっかく会社の Advent Calendar なので少し業務でやったことを書こうと思います。 私は GMO ペパボのセキュリティ対策室という部署で、サービスを横断してセキュリティ対策の基盤作りをしています。 セキュリティ対策と一口に言っても、その内容は多岐にわたりますが、エンジニアのセキュリティレベルの向上支援も業務のひとつです。 例えば年に一度はセキュアコーディング研修を行い、安全なアプリケーションの開発方法を学ぶハンズオンの開催や最新の攻撃手法の共有をしています。 どの分野にもセキュリティはつきものであるため、新しい技術スタックを導入した場合は、そのセキュリティについても啓蒙していくべきだと私は考えています。 例えば Kubernetes もそのうちの一つで、ペパボでも利用が進んでいます。社内のクラスタはセキュリティポリシーを有効にした状態で作成できますが、それが何のためにあるのか、攻撃された場合にどのようなことが生じるのかを知ってほしいと思い、CTF(Capture The Flag) 形式で学べるコンテンツを用意しました。 CTF 形式にした理由 CTF には色々な開催形式がありますが、よくあるのが Jeopardy と呼ばれるもので、与えられた問題を解いて特定のフォーマットの文字列(flag)を探し出すゲームです。 問題は必ず解けるように穴が用意されています。参加者はその穴を探し出して悪用するという攻撃の一連の流れを学ぶことができるため、セキュリティの学習用途として利用されることがあります。 CTF で効率的に学べるかはさておき、面倒だと思われがちなセキュリティを楽しく学ぶには、ゲーミフィケーションを取り入れたほうがより意欲的に取り組めるだろうと思い、CTF 形式のコンテンツにしました。 ちなみに、Kubernetes セキュリティを手を動かしながら学ぶ既存のコンテンツには、次のようなものがあり、いずれも素晴らしいコンテンツです。 https://github.com/madhuakula/kubernetes-goat https://github.com/kubernetes-simulator/simulator https://github.com/ksoclabs/kube-goat https://github.com/securekubernetes/securekubernetes/ kubectf 今回作ったものを mrtc0/kubectf に公開しました。 minikube を使ってローカルに演習環境を構築します。インストーラーが雑なシェルスクリプトなのは許して… 問題は Red Challenge (攻撃) と Blue Challenge (防御) の2種類用意しています。

ping を実行するのに CAP_NET_RAW は必要なくなっていた

必要がなくなっている、というか特定の条件では CAP_NET_RAW は不要という話。 ある講義で Capability について話す機会があり、いつもどおり CAP_NET_RAW が必要な ping を使った実験をしていたところ、環境によっては CAP_NET_RAW File Capability を与えなくても ping が実行できることに気づき、少し調べてみました。 どうも随分前に net.ipv4.ping_group_range というカーネルパラメータが追加されていたらしく、これを設定することで ICMP ソケットを扱うグループを指定できるため、 CAP_NET_RAW や setuid なしで実行できるようになっていたようでした。 以下、調べたことを書いておきます。 ubuntu 18.04 では CAP_NET_RAW なしでは動かないのに対し、ubuntu 20.04 では CAP_NET_RAW がなくても動くようでした。 まずは ubuntu 18.04 で確認してみます。 ubuntu@18.04:~$ uname -a Linux 18.04 4.15.0-109-generic #110-Ubuntu SMP Tue Jun 23 02:39:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ubuntu@18.04:~$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS" ubuntu@18.04:~$ cp `which ping` myping ubuntu@18.

Infra Study Meetup #6 で登壇した

@matsumotory さんからお誘いいただいて、登壇した。 https://forkwell.connpass.com/event/187694/ テーマは「インフラとセキュリティのこれから」ということで、コンテナや Kubernetes のセキュリティについて、DevSecOps の進め方などについて話した。 当日の様子は YouTube に上がっているので、どうぞ。また、使ったコマンドなどは gist にあります。 Infra Study の過去回を見るに、参加者層が幅広い印象を受けていたので、広く浅くセキュリティについて話そうと思った。 Docker などによって Linux コンテナは広く普及し、Linux コンテナの仕組みを理解している人も増える一方で、あまり Linux コンテナ自体(イメージではなく)のセキュリティについて触れている人はそう多くないと感じていた。 また、Kubernetes のセキュリティといえば PodSecurityPolicy 周りについて触れられることが多いが、そもそも Linux コンテナのセキュリティを知らなければ、これを適切に設定することは難しいだろう。加えて Kubernetes の Attack Surfaces やマネージド環境でのセキュリティについて日本語で触れられている記事も多くないので、そのあたりの啓蒙をしようと思い、これらについて話すことにした。 内容としては以前セキュリティ・ミニキャンプなどで行ったコンテナセキュリティの講義からいくつかピックアップしたものに加え、Kubernetes セキュリティについて付け加えた。 …とスライドの内容について書こうと思ったけど、動画を見てもらう方がいいので、ここでは割愛で。 Twitter の様子を見る限り、プラスな反応が多くてよかったと思う(Infra Study の参加者が優しいというのもあるが…)。 自分は質疑応答が本当に苦手で、想定質問をかなり考えて望んだのだけど、思った以上に DevSecOps や組織でのセキュリティ文化についての質問が多くて、想定していた質問は一個もこなかったw slido への質問 当日時間の関係で答えられなかった質問があるので、ここでいくつか回答しようと思う。 https://app.sli.do/event/n9r09kec/live/questions コンテナでイミュータブルだぜ、と言いつつyum updateとかapt upgradeしているかと思うのですが、イミュータブルを目指す環境とアップデートの頻度やライフサイクルの兼ね合いはどのように考えられていますか? コンテナで apt upgrade などをしたことがない… アップデートの頻度は自由に決めていいと思いますが、脆弱性に関してはリスクに応じてすぐに対応する必要があると思います。 イメージをスキャンして、アップデートもしくはパッチを適用して、イメージを再構築するパイプラインやジョブを作って自動化するのが「イミュータブルを目指す環境」には必要だと考えています。 加えるとコンテナ内で root で実行することはベストプラクティスではないので、そこも禁止するべきだと思っています。 脆弱性が頻繁に出るというのは、そもそも不要なパッケージが含まれていたりするケースもあるので、つまるところベストプラクティスを実践していくと、次第にセキュアになっていくと思います。 PaaSのセキュリティについてお聞きしたいです。

procfs の hidepid オプションについて調べた

profs の hidepid オプションの値 procfs のマウントオプションに hidepid というオプションがあることを知った。 man で確認すると 0~3 の値を取るらしい。 hidepid=n (since Linux 3.3) This option controls who can access the information in /proc/[pid] directories. The argument, n, is one of the following values: 0 Everybody may access all /proc/[pid] directories. This is the traditional behavior, and the default if this mount option is not specified. 1 Users may not access files and subdirectories inside any /proc/[pid] directories but their own (the /proc/[pid] directories themselves remain visible).