3-shake SRE Tech Talk #5 ~ コンテナセキュリティ最前線 の資料です。 https://3-shake.connpass.com/event/277945/
runc working directory breakout (CVE-2024-21626) by Mohit Gupta Snyk recently identified a flaw in runc <= 1.1.11, CVE-2024-21626. This issue effectively allowed an attacker to gain filesystem access to the underlying host's OS, which could be used to gain privileged access to the host. This has an impact on orchestration based environments which use runc, such as Kubernetes. An attacker able to d
この連載は、「LXCで学ぶコンテナ入門」というタイトルです。序盤を除くと、LXC自身を紹介するというよりは、Linuxカーネルに実装されているコンテナ関連の機能を紹介をすることが多く、カーネルの機能を紹介する際に、実行例でLXCを使ってきました。その後、LXCを開発しているLinuxContainersプロジェクトからは、コンテナマネージャとしてLXDの開発がスタートし、この連載でもLXDを使ってカーネルの機能を説明することがありました。 LXDは、コンテナと仮想マシンの両方を管理できるマネージャソフトウェアです。LXCもLXDも、OS環境を起動させるシステムコンテナを扱うことを主眼に開発されています。 gihyo.jpでは、LXDについては本連載ではなく、Ubuntu Weekly Recipeで柴田充也さんが頻繁に取り上げており、基本的な操作から応用まで幅広い話題が紹介されています。
Picture by irasutoyaThroughout container lifecycle, pulling image is one of the time-consuming steps. Harter, et al. showed that, pulling packages accounts for 76% of container start time, but only 6.4% of that data is read This has been affecting various kinds of workloads including cold-start of serverless functions, fetching base images during builds, CI/CD cycle, etc. In the community, workaro
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
DockerコンテナイメージをWebAssemblyに変換、Webブラウザ上での実行も可能にする「container2wasm」バージョン0.3が登場 DockerコンテナイメージをWebAssemblyに変換し、WebAssemblyランタイム上で実行可能にするツール「container2wasm」のバージョン0.3がリリースされました。 開発者はNTTの徳永航平氏。container2wasmは実験的なツールとしてオープンソースで公開されています。 バージョン0.3では、RISC-Vアーキテクチャに加えてx86_64アーキテクチャのDockerコンテナイメージにも対応したことが大きな変更点です。 実際にDockerコンテナイメージをWebAssemblyに変換したものをWebブラウザ上で実行できるデモページも用意されました。 下記はインテルの64ビットプロセッサを搭載したWindows
Rootless containers refers to the ability for an unprivileged user to create, run and otherwise manage containers. This term also includes the variety of tooling around containers that can also be run as an unprivileged user. “Unprivileged user” in this context refers to a user who does not have any administrative rights, and is “not in the good graces of the administrator” (in other words, they d
By Yuval Avrahami March 3, 2022 at 5:09 PM Category: Cloud Tags: containers, CVE-2022-0492, Linux, vulnerabilities This post is also available in: English (英語) 概要 2022年2月4日、Linuxはカーネルにおける新たな特権昇格脆弱性CVE-2022-0492を公表しました。CVE-2022-0492はコンテナの基本構成要素であるLinuxの機能、コントロールグループ(cgroup)における論理バグです。この問題は最近発見されたLinuxの権限昇格脆弱性のなかでもとりわけその単純さできわだつもので、「Linuxカーネルが誤って特権的オペレーションを非特権ユーザーに公開してしまった」という内容になっています。 さいわい、ほとんどのコン
恐ろしく長い上に割と複雑なので最後まで読む人はほとんどいないと思うのですが、将来確実に忘れてしまう自分のために書いたので別に悲しくありません。 まえがき 背景 sigstoreの概要 sigstoreを構成するツール群 Cosign Rekor Fulcio 署名方法 コンテナイメージ 鍵ペアの生成 署名 検証 Blobs 鍵ペアの生成 署名 検証 署名の仕組み コンテナイメージ OCI Registryについて 署名の保存先 署名フォーマット 署名検証 検証が不十分な例 Blobs 参考 まとめ まえがき 鍵の管理不要でソフトウェア署名を可能にするKeyless Signingについて解説を書こうと思い、まず前提知識を書いていたら信じられないぐらい長くなったので前提知識だけで1つの記事になりました。 後述するsigstoreは急速に開発が進んでいるプロジェクトであり、ここで書いている記述
こんにちは。インターン生の富田祐永です。普段は情報系の研究室で超伝導量子コンピュータの研究をしています。 2022年1月から約1ヶ月間、NTT 研究所で「コンテナランタイムの実装及び評価」というテーマのインターンに参加させていただいておりました。 インターン参加経緯改めて軽く自己紹介をさせていただきます。 私は今は修士1年の院生なのですが、実は学部時代は情報系ではなく経済学部にいました。また、趣味で何かやっていたというわけでもなかったため、特に低レイヤに関しての実装経験はほぼ皆無です。 院に入ってからも、研究の傍らでちまちまCのコンパイラを書くくらいしか余裕がなく、何か面白いものを集中して実装できる期間が欲しいなあと思っていました。そのため、今回のテーマの募集を見つけた瞬間「これだ!」となって即応募しました。 取り組んだテーマさて、自分が取り組んだのは「containerd-shim-ru
NECサイバーセキュリティ戦略本部セキュリティ技術センターの山﨑です。 今回は、NIST SP800-190 Application Container Security Guide[1](日本語訳版:[2])で言及されているセキュリティリスクのうち、コンテナイメージに関するリスクに着目して紹介します。なお、本ブログにおけるコンテナプラットフォームはDockerを使用するものとして説明します。 コンテナ技術は可搬性の高さや自動化、再利用のしやすさといった特長から近年のシステム構築におけるトレンドとなっています。一方で、コンテナ環境をターゲットとする攻撃事例も日々報告されています。例えば、インターネット上に公開されたDocker APIのエンドポイントを介してマルウェアを感染させる攻撃キャンペーン[3]や、Docker hub上にクリプトマイナーが設置され、2000万回ものダウンロードが行わ
ガイドラインだけでは実感しにくいコンテナセキュリティのリスク マイクロサービスやエッジコンピューティングを実現する技術の一つとして活用が進むコンテナ。その一方で、コンテナやアプリケーション、オーケストレーターの設定不備や運用ミス、脆弱(ぜいじゃく)性などによるセキュリティリスクが数多く指摘されてきた。 こうした事態を受けて、NIST(米国国立標準技術研究所)はセキュリティプラクティスとして「NIST SP800-190 アプリケーションコンテナセキュリティガイド」を公開。情報処理推進機構(IPA)が日本語訳版を出すなど、安全な活用が呼び掛けられている。 ただ、ガイドラインは汎用(はんよう)性を重視するため、「雰囲気は分かるものの、リスクを具体的にイメージしにくい」と、NTTデータのクラウドエンジニア、望月敬太氏は難点を示す。何事においても、どう危険なのかを明確に思い浮かべられないと、対策が
Linux のコンテナ仮想化を構成する機能の一つに Namespace (名前空間) がある。 Namespace は、カーネルのリソースを隔離して扱うための仕組みで、リソース毎に色々とある。 今回は、その中でも PID (Process Identifier) を隔離する PID Namespace を扱ってみる。 使った環境は次のとおり。 $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.3 LTS Release: 20.04 Codename: focal $ uname -rm 5.4.0-96-generic aarch64 $ unshare --version unshare from util-linux 2.34 $ gcc --
はじめに この記事は筆者がKubeCon EU 2021にて発表した「Resource Requests and Limits Under the Hood: The Journey of a Pod Spec」の内容を中心とし、ブログ向けにまとめなおしたものです。 www.youtube.com 日本語でこのリソース要求/制限について内部の仕組みまで踏まえて詳細に書かれた記事はあまりないので、誰かの助けになれば幸いです。 はじめに Kubernetesにおけるリソースの要求と制限 スケジューラーによるスコアリング ノードでのPod作成処理 Requests全体の流れ Limits全体の流れ CRI内部の処理 OCI内部の処理 まとめ Kubernetesにおけるリソースの要求と制限 Kubernetes上でアプリケーションを実行する際、ワークロードの特性に応じて以下のような形で必要なリソ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く