Dockerのポートマッピングのデフォルト設定は危ない - JUNのブログ
あらすじ 公衆WiFiに繋いだ状態でいつものように docker container run -p 8080:80 nginx のような感じでDockerコンテナを動かしていたら、外部からリクエストを受信した。 ファイアウォールを設定し、外部からのアクセスを拒否しているはずなのになぜアクセスできたんだ... 環境 Docker desktop for mac with apple silicon 4.21.0 何が起きた? Dockerはデフォルトの設定では-p 8080:80のようにポートマッピングするとファイアウォールの設定を書き換え、外部からそのポートへのアクセスを許可するようになっている。 その結果LAN内の他のPCから対象ポートにアクセス出来てしまう。 ちなみにこれはDocker公式からも注意が出ている。 Publishing container ports is insecur
Kubernetesのコードリーディングをする上で知っておくと良さそうなこと
Kubernetesとその関連コードのコードリーディングをする上で知っておくと良さそうなことについて知ってる範囲で雑にまとめてみました 前提知識前提として最低限Kubernetesをある程度触っていて KubernetesはPodとかのリソースと呼ばれるものでコンテナだったりロードバランサーとかを管理するようになっていて実際にDeploymentでコンテナを立ててService/Ingressでコンテナで立てたアプリケーションを外部公開できてコンテナはPodという単位でコンテナをグループ化して同一Nodeで実行されるということを知っているくらいがわかっていればまぁ十分なんじゃないかとは思います あとはKubernetesはGoで書かれているので Goの基礎知識とVSCodeやGolandなどGoのコードを読む際に宣言にジャンプできるようなエディタくらいがあると良いと思います Kuberne
Skopeoを利用したコンテナイメージのレジストリ間コピー · Goldstine研究所
こんにちは。もーすけです。 コロナでの在宅に非常にしんどくなってきました。 ブログを書いて気を紛らわしていきたいと思います。 今回は軽めの話題でSkopeoを利用したコンテナイメージのレジストリ間のコピーについてです。 課題感 コンテナレジストリにあるイメージを別のレジストリにコピーしたいと思ったことはないでしょうか。 よくあるシチュエーションとしては、開発環境のKubernetesクラスタで生成したコンテナイメージをプロダクション環境などのほかのレジストリへ移したい。 あるいは、DockerHubにあるイメージを自分たちの管理するレジストリに保管して管理しておきたい。 などがあるかなと思っています。実際にあります。 さらに、このようなコンテナイメージの別レジストリへのコピーをCIパイプラインの中に組み込みたいといったことがあります。 Dockerではだめなのか まず真っ先にレジストリ間の
コンテナユーザなら誰もが使っているランタイム「runc」を俯瞰する[Container Runtime Meetup #1発表レポート]
こんにちは、NTTの徳永です。本稿では、コンテナユーザなら誰もが使っていると言っても過言ではない、コンテナランタイムの筆頭「runc」に注目し、その概要を仕様と実装の両面から俯瞰します。本稿は私が主催者の一人として参加した「Container Runtime Meetup #1」で発表した内容をベースにしています。詳しい内容は発表資料もぜひご参照ください。 コンテナランタイムとはKubernetes等のコンテナオーケストレータを用いてアプリケーションをコンテナ(Pod)として実行するとき、実際にコンテナの作成をしているのは誰でしょうか。実はKubernetesはコンテナを直接触らず、あるソフトウェアを用います。まさにそれがコンテナランタイム（以降、ランタイム）です。つまり、ランタイムはクラスタを構成する各ノード上で稼動し、上位のオーケストレータからの指示に応じ実際にコンテナを作成・管理しま
![コンテナユーザなら誰もが使っているランタイム「runc」を俯瞰する[Container Runtime Meetup #1発表レポート]](https://cdn-ak-scissors.b.st-hatena.com/image/square/2757b228827ed0ff7a4891cb1dc730c4d4c6e047/height=288;version=1;width=512/https%3A%2F%2Fmiro.medium.com%2Fv2%2Fresize%3Afit%3A809%2F1%2AmFt37mfkCaV2P1rprRuwBw.png)
[Container Runtime Meetup] runc & User Namespaces
1. runc & User Namespaces Container Runtime Meetup #1 runcコードリーディング (2019/9/24) 対象とするruncのリビジョン: 7507c64ff675606c5ff96b0dd8889a60c589f14d (2019/9/24時点で最新) 自己紹介 ● GitHub: @AkihiroSuda / Twitter: @_AkihiroSuda_ ● Moby (Docker)、containerd、BuildKitなどのメンテナ ● Rootlessコンテナなどセキュリティ関係を中心に取り組んでいる User Namespaces とは ● 非rootユーザをrootユーザに見せかける ○ もしUserNS内のプロセスに脆弱性があっても、ホストのrootを奪われずにすむ ● UserNS内の見かけ上のroot
![[Container Runtime Meetup] runc & User Namespaces](https://cdn-ak-scissors.b.st-hatena.com/image/square/6abe894e4b274ccfeedde76caf096ac47aca5de3/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fpublicruncusernamespacescontainerruntimemeetup1-190924085316-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
GKE 互換のオンプレコンテナ基盤 AKE (Adtech Container Engine) アーキテクチャ完全公開！ | CyberAgent Developers Blog
GKE 互換のオンプレコンテナ基盤 AKE (Adtech Container Engine) 誕生秘話とアーキテクチャ完全公開！ こんにちは。 アドテクスタジオの Central Infrastructure Agency（CIA） の青山真也です。 本記事は CyberAgent Developers Advent Calendar 2017 の 1 日目の記事となります。 CIA は 15 名程のアドテクスタジオの横軸インフラ組織として、プライベートクラウドの提供や、プライベート/パブリック両方のインフラサポートを行っています。 ちなみにこの Advent Calendar に CIA は 6 名参加（実に 1/4！）してますので、インフラに興味がある方は是非他の記事も読んでみて下さい。 最近ではアドテクスタジオでも、コンテナによる開発が主流となってきており、GKE で開発することが
KubernetesにおけるContainer Storage Interface (CSI)の概要と検証 - Qiita
CSIの概要 Kubernetes v1.9よりContainer Storage Interface (CSI)がAlphaバージョンとしてサポートが開始され、v1.10にてBetaバージョンとしてサポートされています。v1.13でGAになりました。v1.8 までのKubernetesのストレージ関連の機能は、Kubernetesのソースに直に組み込まれる実装("in-tree")で提供されていました。そのため、外部ストレージの開発を行う3rd パーティベンダは、Kubernetes のソースコードへアップストリームする必要があり、リリースのタイミングをKubernetesの開発チームと歩調をあわせる必要がありました。また、v1.8にて追加されたFlexvolumeでは、Kubernetesの Node, MasterのRoot FileSystem にアクセスが必要であり、デプロイが煩
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
