Kubenews #32
2021-09-24
How to deploy a comprehensive DevSecOps solution (click here to source)
RedHat®DevSecOpsフレームワークは、包括的な多層防御セキュリティ戦略の一環として、DevOpsライフサイクル全体の主要なセキュリティ要件に対応します。
Red HatのDevSecOpsフレームワークは、アプリケーションのライフサイクル全体に対応する9つのセキュリティカテゴリと32のメソッドとテクノロジーを識別します。
今回はその中のSecurityカテゴリーに関して書かれている。
Platform security
- Host security
- Container platform security
- lightweight container runtime with CRI-O
- a secure container image registry with Quay.
- Linux namespaces
- teams, groups, and departments間でのapplicationの隔離
- Kubernetes and container hardening
- NIST 800-190 and CIS Benchmarks.
Vulnerability and configuration management
脆弱性および構成管理機能は、アプリケーション、構成、およびコンテナーイメージのセキュリティ上の欠陥を改善、識別、分類、および解決するのに役立ちます。
- Static application security testing (SAST)
- 脆弱性や質の問題に対するコードの解析
- Software composition analysis (SCA)
- 既知の脆弱性やlicensing issueを特定するための依存パッケージ試験
- Interactive application security testing (IAST) and dynamic application security testing (DAST)
- 稼働中のアプリケーションの脆弱性チェック
- Configuration management
- 以下の点のようなGitOpsプロセスで構成を適切に管理することは、セキュリティを強化できます。
- 変更管理の改善
- 攻撃対象領域を減らす可能性のある構成上の欠陥の特定
- 説明責任と改善の機会を高めるための署名や作成者の追跡
- 以下の点のようなGitOpsプロセスで構成を適切に管理することは、セキュリティを強化できます。
- Image risk
- コンテナイメージに関連するリスク
- 脆弱な依存関係
- 埋め込みのSecret
- よろしくない構成
- マルウェア
- 信頼できないImage
- コンテナイメージに関連するリスク
Identity and access management
IDおよびアクセス管理（IAM）メソッドは、ユーザーまたはアプリケーションのIDと管理上定義されたポリシーに基づいて、オンプレミスおよびクラウドの資産、アプリケーション、およびデータへのアクセスを制御します。
- 認証
- 認可
- Identity providers, secrets vaults, and hardware security modules (HSMs)
- セキュリティクレデンシャル、キー、証明書、およびシークレットを管理および保護できます
- Provenance
- デジタル署名または証明記録を通じて、コードまたはImageの身元または信頼性を検証する機能。
Compliance
業界や政府の規制や企業ポリシーを順守するのに役立ちます。
上記のものは、以下のようなものに対するコンプライアンスを向上するのに役立ちます。
- Payment Card Industry Data Security Standard (PCI-DSS)
- ISO 27001 information security management standard
- U.S. Health Insurance Portability and Accountability Act (HIPAA)
- EU General Data Protection Regulation (GDPR)
Network controls
ネットワーク制御とセグメンテーション方法を使用すると、Kubernetesトラフィックを制御、分離、視覚化できます。
- Kubernetes network security policies
- Software-defined networking (SDN)
- A hardened service mesh
- Packet analysis
- API management
Data controls
データ制御の方法とテクノロジーは、データの整合性を保護し、不正なデータ開示を防ぐのに役立ちます。
- Data encryption
- Data protection
Runtime analysis
プロダクションランタイムメソッドは、疑わしいアクティビティや悪意のあるアクティビティをリアルタイムで識別して軽減することにより、クラスターの衛生状態を維持するのに役立ちます。
- Admission controlle
- クラスターでの実行が許可されているものを管理および実施します。
- Runtime application behavioral analysis
- クラスターでの実行が許可されているものを管理および実施します。
- Threat defense and runtime application self protection (RASP)
- サイバー攻撃をリアルタイムで検出してブロックします。
Audit and monitoring
監査および監視方法は、実稼働環境でのセキュリティインシデントに関する情報を提供します。 これらのメソッドは、イベントがいつ発生したかを記述し、考えられる原因と影響の情報を提供して、可視性を向上させ、インシデント対応を加速するのに役立ちます。
- Monitoring
- Security information and event management (SIEM)
- 分散デバイス、エンドポイント、およびアプリケーションからのログとネットワークフローデータを統合することにより、イベントレポートを一元化します。
- Forensics
- セキュリティ違反への洞察を提供し、コンプライアンス監査をサポートする証拠を提供し、復旧作業を加速するための詳細なデータの収集を指します。
Remediation
本番環境でセキュリティインシデントが発生した場合、修復方法は自動的に修正措置を取ります。 これらは、稼働時間を改善し、データの損失を回避するのに役立ちます。
- Security orchestration, automation, and response (SOAR)
- セキュリティインシデントに対応するアクションを自動化し、他のセキュリティツールと統合します。
- Kubernetesの構成エラーとポリシー違反に関連する問題の自動解決。
Elasticsearchによる出前館店舗検索機能のパフォーマンス改善 (click here to source)
オンプレミス上のメインDB(Oracle)の高負荷問題がある一方、スケールアップもスケールアウトも難しい状況であったため、
データ参照用DB(PostgreSQL)をAWSに構築し、データ取得のみ行うAPI（参照系API）のDBアクセスを参照用DBに向ける、というプロジェクトが発足した際の話についてです。
本記事では、参照用DBへの移行後、店舗検索機能にElasticsearchを導入することで、パフォーマンス改善を行ったプロジェクトについて紹介されています。
vclusterにCustom Controller/Admission Webhookをデプロイしてみる(click here to source)
仮想クラスタにOperatorをデプロイする際の手順について書かれています。
NSA & CISA Kubernetes Security Guidance – A Critical Review (click here to source)
先日、米国の国家安全保障局（NSA）と、サイバーセキュリティおよびインフラストラクチャセキュリティ庁（CISA）は、Kubernetesクラスターに適用することを推奨するセキュリティ強化の詳細を示すサイバーセキュリティテクニカルレポート（CTR）をリリースしました。
この記事は、以下の三つに関して書かれている。
- Good
- Bad
- NSA / CISAガイダンスがKubernetesセキュリティの重要な側面を見落としていた場所、またはガイダンスが公開された時点で古くなっていた場所。
- Complex
- CTRガイダンスでカバーされていない、より一般的な複雑なユースケースのいくつかに関する考慮事項。
- これには、過度なレベルの計算能力やストレージを必要としない有用な監査構成、外部依存関係の処理、Kubernetes RBACの複雑なメカニズムに関する注意事項が含まれます。
Good
- Container Imagesのスキャン
- 最小な権限の原則に従う
- ネットワークの分離
- ロギング構成
- 定期的な構成レビュー
Bad
- PSPの廃止
- アドミッションコントローラー
- 矛盾/誤った情報
- ガイダンスの4ページには、KubeletとSchedulerの両方がデフォルトでTCP10251で実行されると記載されています。実際には、Kubeletのデフォルトポートは、読み取り/書き込みポートの場合はTCPポート10250であり、間もなく廃止される読み取り専用ポートの場合は10255です。
- 認証の問題
Complex
- 監査データのレベル
- サイドカーのリソース要件
- 外部依存関係は不可欠であること。
- RBACは難しい
- すべてにパッチを当てるのは難しい
DataRoaster is now open-sourced, why I created it (click here to source)
DataRoaster github
DataRoasterは、kubernetesで実行されるデータプラットフォームを提供するツールです。
DataRoasterが提供するデータプラットフォームには以下のようないくつかのコンポーネントがあります。
- Hive MetaStore
- メタデータを管理するデータベース
- Spark Thrift Server
- trino (github)
- 高速な分散SQLクエリエンジン
- redash
- jupyterhub
- ブラウザからアクセス/実行できるユーザ認証機能つきJupyterサーバー
- kafka
DataRoasterデモ
7 Microservices Best Practices for Developers (click here to source)
マイクロサービスのメリットと課題
メリット
課題
- サービス間通信
- セキュリティレイヤー
- モノリスアプリケーションでの認証と承認は、エントリの時点で1回処理できます。
- マイクロサービスへの移行に伴い、すべてのマイクロサービスは、アクセス制御を実施するために何らかの認証と承認を実行する必要があります。
- スケーラビリティ
- マイクロサービスを使用すると、独立した機能をすばやく拡張できますが、これを効果的に行うには、優れたアプリ管理とさらに優れたツールが必要です。
マイクロサービスのベストプラクティス
1.小さなアプリケーションドメイン
マイクロサービス戦略を採用するには、単一責任の原則を採用する必要があります。
単一のサービスに対する責任の範囲を制限することにより、そのサービスの失敗による悪影響を制限します。
2.データストレージの分離
同じデータベースに接続する複数のマイクロサービスは、本質的には依然としてモノリシックアーキテクチャです。
モノリスは、アプリケーション層ではなくデータベース層にあるため、同じように壊れやすくなっています。各マイクロサービスには、可能な限り、独自のデータ永続化レイヤーが必要です。
これにより、他のマイクロサービスからの分離が保証されるだけでなく、特定のデータセットが使用できなくなった場合の爆風半径が最小限に抑えられます。
ファイルストアについても同様のケースを作成できます。
マイクロサービスアーキテクチャを採用する場合、同じファイルストレージサービスを使用するために個別のマイクロサービスを用意する必要はありません。
ファイルの実際の重なりがない限り、個別のマイクロサービスには個別のファイルストアが必要です。
3.通信チャネル
マイクロサービスが相互に通信する方法、特に関心のあるイベントに関しては、慎重に検討する必要があります。
そうしないと、単一の利用できないサービスが通信障害につながり、アプリケーション全体が崩壊する可能性があります。
マイクロサービス間の通信には、同期と非同期の2種類があります。
マイクロサービス間の同期通信では、チェーン内のリンクが切断されると機能しなくなってしまう依存関係チェーンが作成される可能性があります。
一方非同期通信では、サービスは要求を送信し、応答を待たずにその存続期間を継続します。
非同期通信への単純ですが効果的なアプローチは、パブリッシュ/サブスクライブパターンを採用することです。
対象のイベントが発生すると、プロデューサー（この場合はマイクロサービス）はそのイベントのレコードをメッセージキューサービスに公開します。
そのタイプのイベントに関心のある他のマイクロサービスは、そのイベントのコンシューマーとしてメッセージキューサービスにサブスクライブします。
4.互換性
可能な限り、下位互換性を維持して、コンシューマーが壊れたAPIに遭遇しないようにします。
一般的な方法は、/api/v1または/api/v2のようなパスレベルの互換性保証に従うことです。
後方互換性のない変更は、/api/v3のような新しいパスに移動します。
5.マイクロサービスのオーケストレーション
マイクロサービスのオーケストレーションは、プロセスとツールの両方で成功するための重要な要素です。
技術的には、systemdやDocker、podmanなどを使用して仮想マシンでコンテナーを実行できますが、コンテナーオーケストレーションプラットフォームと同じレベルの復元力は提供されません。
効果的なマイクロサービスオーケストレーションのために、バトルテスト済みのコンテナオーケストレーションプラットフォームに依存することをお勧めします。その分野の明確なリーダーはKubernetesです。
6.マイクロサービスのセキュリティ
セキュリティポリシーを適用するための一元化されたシステムは、悪意のあるユーザー、侵入型ボット、および欠陥のあるコードからアプリケーション全体を保護するために不可欠です。
7.メトリクスとモニタリング
(省略)
Kubenews #31
2021-09-17
Kubernetes CI/CD pipelines: What, why, and how (click here to source)
このブログの対象読者
- エンタープライズソフトウェアとの旅の始まりにいる開発者
- 会社のアプリケーションに取り組んでいる経験豊富なソフトウェアエンジニア
- チームの生産性を向上させようとしているエンジニアリングリード
CI / CDパイプラインとは何
CI / CDパイプラインは、コード開発から本番展開まで、ソフトウェアが通過する一連の段階と自動化されたステップです。
CIは「継続的インテグレーション」の略で、ソフトウェアビルドパイプラインを指します。
CIには、開発者がコードを記述してからチームテスト段階にプッシュするまでのすべての手順が含まれています。
CDはソフトウェアリリースパイプラインを指し、「継続的デリバリー」または「継続的展開」のいずれかを表すことができます。
CDとは、一連の環境にコードをデプロイすることにより、コードが目的の機能を提供することを検証することであり、ソフトウェアを実際に本番環境に展開する前に、ソフトウェアが最終的に実行される実際の本番環境を複製することを目的としています。
Kubernetes CI / CDのメリットは何？
CI / CDワークフローとクラウドネイティブシステムには、いくつかの共通の目標があります。
どちらも、開発速度の向上、ソフトウェア品質の最適化、および操作性の維持を試みます。
CI / CDは、コードが開発されてから本番環境にリリースされるまでの多くのステップを自動化し、Kubernetesは、さまざまなインフラストラクチャ環境でのコンテナのデプロイを自動化し、効率的なリソースの利用を保証します。
組み込みのコンテナレジストリが付属しており、次の3つの方法でKubernetesと統合できます。
- GitLab CIパイプラインに組み込まれたソフトウェアは、CDステージの一部としてKubernetesにデプロイできます
- Kubernetesは、GitLabインスタンスにリンクされているバッチジョブの実行を管理できます
- GitLabインスタンス自体はKubernetesクラスターで実行できます
How Docker broke in half (click here to source)
1. Dockerが誕生
「パリのSolomonHykesによって2008年にDotCloudとして設立されたDockerとなる会社は、当初、開発者がアプリケーションを簡単に構築して出荷するためのサービスとしてのプラットフォーム（PaaS）として設計されました。」
という始まりから、Dockerの初期について書かれています。
2. オープンソースの商業化は難しい
当時どういう考えを持っていたのかや、実際に商用製品を出してみての結果について書かれています。
3. Kubernetesの決定
DockerとKubernetesの立ち位置や、DockerとKubernetesのコラボレーションはうまくいかなかった話について書かれています。
4. 上部の緊張
以下の２つのDockerが生まれる話などがされています。
- DockerCommunityEditionは、開発者向けの非常に人気のあるコマンドラインツールおよびオープンソースプロジェクト
- Docker Enterprise Editionは、大規模なコンテナーを採用したい企業顧客向けの一連の商用ツール
5. Dockerが2つに分かれる
Dockerは2019年11月にビジネスのエンタープライズ部分をMirantisに売却し、DockerEnterpriseはMirantisKubernetesEngineに吸収された話が書かれています。
6. 今日のDockerはどこにある？
- 先週、DockerはDockerソフトウェアのライセンス条項の変更を発表したよ
- 新しい開発者ツール, 安全で検証済みのimageといった信頼できるコンテンツの構築などに「Docker2.0」の成長の機会を見出している。
など、今後の展望や考えについて書かれている。
Integrating Keycloak and Open Policy Agent (OPA) with Confluent (click here to source)
OAuth2認証にKeycloakを使用し、ConfluentKafka内のトピックレベルの承認にOpenPolicy Agent（OPA）を使用する方法について書かれています。
Kubenews #30
2021-09-10
Managing Kubernetes seccomp profiles with security profiles operator (click here to source)
seccompプロファイルの作成と管理は煩雑であり、エラーが発生しやすくなるのを緩和する目的で作成された。
セキュリティプロファイルオペレータの機能
- SeccompプロファイルCRD
- seccompプロファイルをポッドにバインドするためのCRD
- 実行中のポッドからseccompプロファイルを作成するためのCRD
- Seccompプロファイルの同期とノードサポートの検証
- メトリックス
- ログエンリッチャー
インストール
cert-managerをインストールする必要があります。
$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.4.2/cert-manager.yaml
次にservice profile operatorのインストール
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/security-profiles-operator/master/deploy/operator.yaml
seccomp profileの作成
以下のプロファイルは、SCMP_ACT_LOGのデフォルトアクションのみを設定します。
profile1.yaml という名前でファイルを作成します。
apiVersion: security-profiles-operator.x-k8s.io/v1alpha1 kind: SeccompProfile metadata: namespace: default name: profile1 spec: defaultAction: SCMP_ACT_LOG
では、作成していきます。
$ kubectl apply -f profile1.yaml seccompprofile.security-profiles-operator.x-k8s.io/profile1 created $ kubectl get seccompprofile profile1 --output wide NAME STATUS AGE LOCALHOSTPROFILE profile1 Installed 7m21s operator/default/profile1.json
作成されたプロファイルは、
/var/lib/kubelet/seccomp/operator/<namespace>/<profile name>.json
に格納されます。
$ ssh k8s-pool1-18290975-vmss000000 sudo cat /var/lib/kubelet/seccomp/operator/default/profile1.json
{"defaultAction":"SCMP_ACT_LOG"}
seccomp profileの利用
作成したprofileをPodに適用してきます。
apiVersion: v1 kind: Pod metadata: name: nginx spec: securityContext: seccompProfile: type: Localhost localhostProfile: operator/default/profile1.json containers: - name: nginx image: nginx
プロファイルの継承
1つのprofileをベースとして使用して新しいカスタムプロファイルを作成することもできます。
apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: SeccompProfile
metadata:
namespace: default
name: inheritance-profile1
spec:
defaultAction: SCMP_ACT_ERRNO
baseProfileName: base-profile1
syscalls:
- action: SCMP_ACT_ALLOW
names:
- mkdir
profile bindings
PodのSpecを直接いじりたくない場合に、ProfileBindingが有用である。
今回は、nginx:1.21.1のimageを使用するPodに対して、最初に作成した profile1を適用させる例を紹介します。
apiVersion: security-profiles-operator.x-k8s.io/v1alpha1 kind: ProfileBinding metadata: name: nginx-binding spec: profileRef: kind: SeccompProfile name: profile1 image: nginx:1.21.1
適用します。
$ kubectl apply -f nginx-binding.yaml profilebinding.security-profiles-operator.x-k8s.io/nginx-binding created
以下のprofileを指定していないPodを作成すると挙動が確認できます。
$ cat <<EOF kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.21.1
EOF
pod/nginx created
$ kubectl get pod nginx -o jsonpath='{.spec.containers[*].securityContext.seccompProfile}'
{"localhostProfile":"operator/default/profile1.json","type":"Localhost"}
profileの記録
以下のmanifestを適用した場合、app: nginx というラベルを持ったPodが作成された際に記録が開始されます。
そして、そのポッドが削除されると、seccompプロファイルリソース（ポッドごと）が作成され、使用できるようになります。
apiVersion: security-profiles-operator.x-k8s.io/v1alpha1 kind: ProfileRecording metadata: name: recording spec: kind: SeccompProfile recorder: hook podSelector: matchLabels: app: nginx
Shipwright - Building Container Images In Kubernetes (click here to source)
Shipwrightとという、Kubernetes上でコンテナイメージを作成するツールが紹介されています。
リソースとしては、
- BuildStrategy or ClusterBuildStrategy
- Build
- BuildRun
BuildStrategy or ClusterBuildStrategy
BuildのManifestで指定する、コンテナイメージをビルドする際に使用するツールについてです。
現在は、以下の選択肢があるみたいです。
- Available ClusterBuildStrategies
| Name | Supported platforms |
|---|---|
| buildah | linux/amd64 only |
| BuildKit | all |
| buildpacks-v3-heroku | linux/amd64 only |
| buildpacks-v3 | linux/amd64 only |
| kaniko | all |
| ko | all |
| source-to-image | linux/amd64 only |
- Available BuildStrategies
| Name | Supported platforms |
|---|---|
| buildpacks-v3-heroku | linux/amd64 only |
| buildpacks-v3 | linux/amd64 only |
Build
ここで、実際にどうビルドするのかを定義します。
spec.source.url: アプリケーションのソースコードのあるレポジトリを指定spec.strategy: ビルドツールを指定spec.output: 作成したimageをプッシュするregistryを指定output.credentials.name: registryにアクセスする際に使用する既存のsecretを指定
apiVersion: shipwright.io/v1alpha1
kind: Build
metadata:
name: s2i-nodejs-build
spec:
source:
url: https://github.com/shipwright-io/sample-nodejs
strategy:
name: kaniko
kind: ClusterBuildStrategy
output:
image: us.icr.io/source-to-image-build/nodejs-ex
credentials:
name: icr-knbuild
例えば、
- レポジトリのrootディレクトリにソースコードがない場合は、
spec.source.contextDirにて指定 - 独自のビルドツールを積んでいるimageを使う場合、
spec.strategy.nameをsource-to-imageにし、spec.builder.imageにてそのimageを指定する
など、柔軟性がありそう。
apiVersion: shipwright.io/v1alpha1
kind: Build
metadata:
name: s2i-nodejs-build
spec:
source:
url: https://github.com/shipwright-io/sample-nodejs
contextDir: source-build/
strategy:
name: source-to-image
kind: ClusterBuildStrategy
builder:
image: docker.io/centos/nodejs-10-centos7
output:
image: us.icr.io/source-to-image-build/nodejs-ex
credentials:
name: icr-knbuild
BuildRun
Kubernetes上でBuildを実行するリソース。
apiVersion: shipwright.io/v1alpha1
kind: BuildRun
metadata:
name: buildpack-nodejs-buildrun-namespaced
spec:
buildRef:
name: s2i-nodejs-build
serviceAccount:
name: pipeline
Buildで定義したプッシュ先を上書きしたい場合、このリソースでも定義ができる。
apiVersion: shipwright.io/v1alpha1
kind: BuildRun
metadata:
name: buildpack-nodejs-buildrun-namespaced
spec:
buildRef:
name: s2i-nodejs-build
serviceAccount:
name: pipeline
output:
image: us.icr.io/source-to-image-build/nodejs-ex
credentials:
name: icr-knbuild
Distributed tracing with Knative, OpenTelemetry and Jaeger (click here to source)
Knative、OpenTelemetry、Jaegerを使った分散トレーシングについて書かれています。
Setup
既にKnative Serving and Eventingがデプロイされてていることを前提としています。
まず、クラスターにOpenTelemetryオペレーターを追加します。 こちらは、cert-managerに依存しているため、そちらもデプロイします。
$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml $ kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml
次に、イェーガーオペレーターをデプロイします。
$ kubectl create namespace observability
$ kubectl create -n observability \
-f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/master/deploy/crds/jaegertracing.io_jaegers_crd.yaml \
-f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/master/deploy/service_account.yaml \
-f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/master/deploy/role.yaml \
-f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/master/deploy/role_binding.yaml \
-f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/master/deploy/operator.yaml
起動したら、次のコマンドを実行してJaegerインスタンスを作成できます。
$ kubectl apply -n observability -f - <<EOF apiVersion: jaegertracing.io/v1 kind: Jaeger metadata: name: simplest EOF
次に、OpenTelemetryコレクターを作成します。
$ kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: otel
namespace: observability
spec:
config: |
receivers:
zipkin:
exporters:
logging:
jaeger:
endpoint: "simplest-collector.observability:14250"
insecure: true
service:
pipelines:
traces:
receivers: [zipkin]
processors: []
exporters: [logging, jaeger]
EOF
最後に、すべてのトレースがコレクターを指すようにEventing andServingを構成します。
$ for ns in knative-eventing knative-serving; do
kubectl patch --namespace "$ns" configmap/config-tracing \
--type merge \
--patch '{"data":{"backend":"zipkin","zipkin-endpoint":"http://otel-collector.observability:9411/api/v2/spans", "debug": "true"}}'
done
Hello World
トレースインフラストラクチャがすべてデプロイおよび構成されたので、ハートビートイメージ をContainerSourceとして デプロイして、 すべてが正しく接続されていることをテストおよび確認できます。
$ kubectl apply -f - <<EOF
apiVersion: sources.knative.dev/v1
kind: ContainerSource
metadata:
name: heartbeats
spec:
template:
spec:
containers:
- image: gcr.io/knative-nightly/knative.dev/eventing/cmd/heartbeats:latest
name: heartbeats
args:
- --period=1
env:
- name: POD_NAME
value: "heartbeats"
- name: POD_NAMESPACE
value: "default"
- name: K_CONFIG_TRACING
value: '{"backend":"zipkin","debug":"true","sample-rate":"1","zipkin-endpoint":"http://otel-collector.observability:9411/api/v2/spans"}'
sink:
uri: http://dev.null
EOF
今のところ、このコンテナは存在しないドメインhttp：//dev.nullにハートビートを送信しているだけなので、このポッドのログを見ると、一連のDNS解決エラーが表示されますが、otel-collectorポッドのログを調べると、サービスからトレースを正常に受信していることがわかります。
ハートビートを受信するためにKnativeサービスを追加し、ハートビートサービスを更新します。
$ kubectl apply -f - <<EOF
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: event-display
spec:
template:
spec:
containers:
- image: gcr.io/knative-nightly/knative.dev/eventing/cmd/event_display:latest
env:
- name: K_CONFIG_TRACING
value: '{"backend":"zipkin","debug":"true","zipkin-endpoint":"http://otel-collector.observability:9411/api/v2/spans"}'
EOF
$ kubectl apply -f - <<EOF
apiVersion: sources.knative.dev/v1
kind: ContainerSource
metadata:
name: heartbeats
spec:
template:
spec:
containers:
- image: gcr.io/knative-nightly/knative.dev/eventing/cmd/heartbeats:latest
name: heartbeats
args:
- --period=1
env:
- name: POD_NAME
value: "heartbeats"
- name: POD_NAMESPACE
value: "default"
- name: K_CONFIG_TRACING
value: '{"backend":"zipkin","debug":"true","zipkin-endpoint":"http://otel-collector.observability:9411/api/v2/spans"}'
sink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: event-display
EOF
これらのサービスがデプロイされたら、Jaegerダッシュボードでもう一度確認することで、おもしろいとレースが表示されます。
Getting fancy
Hello Worldより複雑な構成を紹介してくれているので、記事を読んでみてください。
Kubenews #extra-001
2021-09-**
配信なし
monday.com’s Multi-Regional Architecture: A Deep Dive (click here to source)
マルチリージョンに移行することを決定するときは、パフォーマンス優先、復元力優先、プライバシー優先等の優先事項に対する設計間で作業が大きく異なるため、主な動機を理解する必要があります。
プラットフォームを複数の地域で実行するに至る3つの主な動機
パフォーマンス
- サーバーを顧客の近くで実行すると、待ち時間が短くなり、接続品質が向上し（特にモバイルで）、一般的にエンドユーザーのエクスペリエンスが向上します。
-
- 任意のリージョンにおいて任意の時点でユーザーにサービスを提供できる場合、複数のリージョンでシステムを同時に実行することは、システムの全体的なフォールトトレランスの向上、ダウンタイムの短縮につながる。
プライバシーとコンプライアンス
- 顧客が世界のどこにデータを保存するかを選択できるようにすることで、明確な競争上の優位性が生まれ、PIIや機密情報を処理するヘルスケア、銀行、企業などの厳しく規制された業界との連携への扉が開かれます。
2番目のリージョンを追加する際の課題
【課題1】 サブドメインは基本的にスラッグであるが、完全ではない。
ユニークなサブドメインを使えるものもあれば、すべての顧客が使用する共有サブドメインがも存在してしまう。
【課題2】ユーザーが誰であるかさえわからない場合がある。
ログインフローにおいて、匿名の訪問者がプラットフォームに到着し、電子メールとパスワードを入力して、最終的にアカウントにルーティングされる際に、すべてのユーザーが同じサブドメインにアクセスします。
この時、どのリージョンがログインフローを処理するのか。
【課題3】可能な限りベンダーに中立を保つ
アーキテクチャを単一のネットワークサービスプロバイダーにチェーンした場合、いざ大規模な停止が起こった際に、インフラストラクチャ全体を再構築せずに回復することが難しい。
【課題4】再現性
簡単に複製できる方法で新しいリージョンを構築したかった。
monday.comのマルチリージョンデザイン
設計の重要なポイントとして以下を上げている。
- 各リージョンの独立
- ユーザーは各リージョンに直接アクセス可能
- 認証はグローバル
- ベンダー中立性
そのほか、処理の流れの説明が書かれています。
マルチリージョンをサポートするためのアンバサダーの構成
前で説明したことを基に、マルチリージョンネットワーク、認証サービス、API構造を結び付ける構成について、深く掘り下げて説明がされています。
マルチリージョンでのアプリケーションの展開
次の3つのデプロイトポロジをサポートしているようです。
Regional
地域ごとに分けて展開されるアプリケーションは、独立したコンポーネントとしてあらゆるリージョンに展開されます。
各デプロイメントは、地域ごとに独立していて、データを共有せず、互いを認識しないようになっています。
Global
- グローバルなアプリケーションは米国で一度展開され、すべての地域から内部ネットワークを介してアクセスできるようになっている。
Replicated
- レプリケートされたアプリケーションはすべてのリージョンに独立してデプロイされますが、データベースに関しては単一のレプリケートされたものを共有し、それらの状態はすべてのリージョンで同じものになっている。
ロギングとモニタリング
Kubernetes Supply Chain Policy Management with Cosign and Kyverno (click here to source)
以前は、connaseiurというツールを紹介しました。
今回はみんな大好きkyverno!
Image Signing with Cosign
cosign (github)
Generate a keypair
$ cosign generate-key-pair Enter password for private key: Enter again: Private key written to cosign.key Public key written to cosign.pub
- Sign a container and store the signature in the registry
$ cosign sign -key cosign.key dlorenc/demo Enter password for private key: Pushing signature to: index.docker.io/dlorenc/demo:sha256-87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8.sig
- Verify a container against a public key
$ cosign verify -key cosign.pub dlorenc/demo
The following checks were performed on these signatures:
- The cosign claims were validated
- The signatures were verified against the specified public key
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"sha256:87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8"},"Type":"cosign container image signature"},"Optional":null}
Cosign Image Signature Verification with Kyverno
「ghcr.io/kyverno/」リポジトリの「test-verify-image」という名前で始まるのすべてのイメージを対象として、cosignの共通鍵で複合化できるのかを確認してくれる。
apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: check-image spec: validationFailureAction: enforce background: false rules: - name: check-image match: resources: kinds: - Pod verifyImages: - image: "ghcr.io/kyverno/test-verify-image:*" key: |- – ---BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8nXRh950IZbRj8Ra/N9sbqOPZrfM 5/KAQN0/KjHcorm/J5yctVd7iEcnessRQjU917hmKO6JWVGHpDguIyakZA== – ---END PUBLIC KEY--- –
署名されたimageを使ってdeployすると通ります。
kubectl create deployment signed \ --image=ghcr.io/kyverno/test-verify-image:signed
署名されてないimageを使った場合、kyvernoによって弾かれる。
kubectl create deployment unsigned \
--image=ghcr.io/kyverno/test-verify-image:unsigned
error: failed to create deployment: admission webhook "mutate.kyverno.svc" denied the request:
resource Deployment/default/unsigned was blocked due to the following policies
verify-image:
autogen-verify-image: 'image verification failed for ghcr.io/kyverno/test-verify-image:unsigned:
signature not found'
別のキーペアにおける鍵で署名されたimageも通りません。
kubectl create deployment signed-other \
--image=ghcr.io/kyverno/test-verify-image:signed-by-someone-else
error: failed to create deployment: admission webhook "mutate.kyverno.svc" denied the request:
resource Deployment/default/signed-other was blocked due to the following policies
verify-image:
autogen-verify-image: 'image verification failed for ghcr.io/kyverno/test-verify-image:signed-by-someone-else:
invalid signature'
Audit Logging in Clusters (click here to source)
Falcoを使用した監査ログの検索について書かれています。
監査ポリシー
監査ポリシーは、監査ログの構成を定義します。どのイベントが監査の対象に入るのかを制御します。
パラメータ「omitStages」を使用して、リクエストがログに記録されないようにする対象を定義できます。
監査ポリシーのYAMLファイル
apiVersion: audit.k8s.io/v1 # This is required. kind: Policy # Don't generate audit events for all requests in RequestReceived stage. omitStages: - "RequestReceived" rules: # Log pod changes at RequestResponse level - level: RequestResponse resources: - group: "" # Resource "pods" doesn't match requests to any subresource of pods, # which is consistent with the RBAC policy. resources: ["pods"] # Log "pods/log", "pods/status" at Metadata level - level: Metadata resources: - group: "" resources: ["pods/log", "pods/status"] # Don't log requests to a configmap called "controller-leader" - level: None resources: - group: "" resources: ["configmaps"] resourceNames: ["controller-leader"]
リクエストのステージ
リクエストをログに記録できる4つの段階は、次のように定義されています。
RequestReceived
- サーバーが応答の発行を開始する前の段階。
ResponseStarted
- リクエストのヘッダーの作成は完了したが、レスポンスの本文は送信されていない段階。
ResponseComplete
- リクエストに対するレスポンスボディが完了した段階。
Panic
- パニックが発生した段階。
イベントのレベル
None
- このルールに一致するイベントはログに記録されません。
Metadata
Request
RequestResponse
パラメータ「rules」は、監査ポリシーYAMLファイルで必要な唯一のパラメータです。
ここで、どのリクエストをどのレベルでログに記録するかを定義できます。
たとえば、先ほどの例の最初のruleは、Podのすべての変更がRequestResponseレベルでログに記録されることを示しています。
監査のバックエンド
監査ログを外部ストレージに書き込むことに関して、２つの方法があります。
ログバックエンド
- JSONlines形式を使用して、ログをファイルシステムに書き込みます
webhookバックエンド
- イベントを外部HTTPAPIに送信します
kubescape (click here to source)
Kubernetes Hardening Guidance by NSA and CISAに基づいて、Cluster内のリソースをチェックしてくれます。
$ kubescape scan framework nsa --exclude-namespaces kube-system,kube-public
ARMO security scanner starting
[progress] Downloading framework definitions
[success] Downloaded framework
[progress] Accessing Kubernetes objects
W0831 18:12:29.875935 241 warnings.go:70] batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob
[success] Accessed successfully to Kubernetes objects, let’s start!!!
[progress] Scanning cluster
◑ [success] Done scanning cluster
[control: Allow privilege escalation] passed 👍
Description: Attackers may gain access to a container and uplift its privilege to enable excessive capabilities.
Summary - Passed:1 Failed:0 Total:1
・・・
[control: Control plane hardening] passed 👍
Description: Kubernetes control plane API is running with non-secure port enabled which allows attackers to gain unprotected access to the cluster.
Summary - Passed:1 Failed:0 Total:1
[control: Dangerous capabilities] passed 👍
Description: Giving dangerous and unnecessary capabilities for a container can increase the impact of a container compromise.
Summary - Passed:1 Failed:0 Total:1
・・・
[control: Privileged container] failed 😥
Description: Potential attackers may gain access to privileged containers and inherit access to the host resources. Therefore, it is not recommended to deploy privileged containers unless it is absolutely necessary.
Namespace kube-image
DaemonSet - builder
Summary - Passed:0 Failed:1 Total:1
Remediation: Change the deployment and/or pod definition to unprivileged. The securityContext.privileged should be false.
・・・
+-------------------------------------------------+------------------+---------------+-----------+
| CONTROL NAME | FAILED RESOURCES | ALL RESOURCES | % SUCCESS |
+-------------------------------------------------+------------------+---------------+-----------+
| Allow privilege escalation | 0 | 1 | 100% |
| Allowed hostPath | 1 | 1 | 0% |
| Anonymous requests | 0 | 0 | NaN |
| Applications credentials in configuration files | 3 | 4 | 25% |
| Automatic mapping of service account | 3 | 3 | 0% |
| Cluster-admin binding | 4 | 122 | 96% |
| Container hostPort | 1 | 1 | 0% |
| Control plane hardening | 0 | 1 | 100% |
| Dangerous capabilities | 0 | 1 | 100% |
| Exec into container | 4 | 122 | 96% |
| Exposed dashboard | 0 | 2 | 100% |
| Host PID/IPC privileges | 1 | 1 | 0% |
| Immutable container filesystem | 1 | 1 | 0% |
| Ingress and Egress blocked | 1 | 1 | 0% |
| Insecure capabilities | 0 | 1 | 100% |
| Linux hardening | 1 | 1 | 0% |
| Non-root containers | 0 | 1 | 100% |
| Privileged container | 1 | 1 | 0% |
| Resource policies | 1 | 1 | 0% |
| hostNetwork access | 1 | 1 | 0% |
+-------------------------------------------------+------------------+---------------+-----------+
| 20 | 23 | 267 | 91% |
+-------------------------------------------------+------------------+---------------+-----------+
Writing a Kubernetes Validating Webhook using Python (click here to source)
Validating Webhookを実行するコンテナをPythonを用いて作成する方法について書かれています。
How to Secure Containers with Cosign and Distroless Images (click here to source)
Distroless Container Imagesとは何か。
Distroless Container Imagesは、「言語に焦点を合わせたDockerイメージからオペレーティングシステムを除いたもの」です。つまり、アプリケーションとそのランタイム依存関係のみが含まれ、他の通常のOSパッケージマネージャー、Linuxシェル、または標準のLinuxディストリビューションで通常期待されるようなプログラムは含まれません。
ディストロレスコンテナイメージと一緒にCosignが必要な理由
Cosignの必要性は、ディストロレスイメージを使用しても、タイポスクワッティング攻撃や悪意のあるイメージの受信などのセキュリティ上の脅威に直面する可能性があるためです。
Cosign検証を使用した、ディストロレスコンテナのベースイメージの検証。
こちらでは、実際にディストロレスコンテナイメージとcosignを使用したDemoを紹介してくれています。
Easy, Secure Kubernetes Authentication With Pinniped (click here to source)
Pinnipedについて、Demoを交えて説明してくれています。
Kubenews #29
2021-08-20
Encrypt your Kubernetes Secrets with Mozilla SOPS (click here to source)
Kubernetes Secretsは、base64で暗号化されていて、簡単に複合化できてしまう。 そのソリューションとして、Mozilla SOPSがある。
・特徴
以下のようなSolutionと連携が可能
この記事では、Azureに関しての例が書かれており、Azure Service Principal (SP) を使うことを推奨しています。
- Provision an Azure Service Principal (SP)
# create a service principal
az ad sp create-for-rbac -n sp-sops-keyvault -o json
# {
# "appId": "00000000-0000-0000-000000000000",
# "displayName": "http://sp-sops-keyvault",
# "name": "http://sp-sops-keyvault",
# "password": "00000000-0000-0000-000000000000",
# "tenant": "<your_tenant_identifier>
# }
export AZURE_CLIENT_ID=<appId>
export AZURE_CLIENT_SECRET=<password>
export AZURE_TENANT_ID=<tenant>
- Provisioning an Azure Key Vault instance
# create a new Resource Group az group create -n rg-sops-sample -l germanywestcentral # create a Key Vault instance az keyvault create -n kv-sops-sample \ -g rg-sops-sample \ -l germanywestcentral # create an access policy for the SP az keyvault set-policy -n kv-sops-sample \ -g rg-sops-sample \ --spn $AZURE_CLIENT_ID \ --key-permissions encrypt decrypt
- Create a key in Azure Key Vault for encryption & decryption
# create an key for encryption / decryption
az keyvault key create -n sops-sample-key \
--vault-name kv-sops-sample \
--ops encrypt decrypt \
--protection software
# read and store key identifier
export KEY_ID=$(az keyvault key show -n sops-sample-key \
--vault-name kv-sops-sample \
--query key.kid -o tsv)
- Install Mozilla SOPS
# download sops cli for macOS curl -O -L -C - https://github.com/mozilla/sops/releases/download/v3.7.1/sops-v3.7.1.darwin # move and rename the cli to /usr/bin sudo mv sops-v3.7.1.darwin /usr/bin/sops # make it executable sudo chmod +x /usr/bin/sops
- Encrypt Kubernetes Secrets
まず、Sercretを作成します。
# create the Kubernetes secret
kubectl create secret generic demo \
--from-literal mysecret=secret_value \
-o yaml \
--dry-run=client > secret.encoded.yml
# print the contents of secret.encoded.yml
cat secret.encoded.yml
# apiVersion: v1
# data:
# mysecret: c2VjcmV0X3ZhbHVl
# kind: Secret
# metadata:
# creationTimestamp: null
# name: demo
sopsコマンドを用いて、暗号化します。
# encrypt secret.encoded.yml using SOPS
sops --encrypt --encrypted-regex '^(data|stringData)$' \
--azure-kv $KEY_ID secret.encoded.yml > secret.encrypted.yml
# print the contents of secret.encrypted.yml
cat secret.encrypted.yml
# apiVersion: v1
# data:
# mysecret: ENC[AES256_GCM,data:gz/WAjWte3bCnNm6e+G4ow==,iv:VB4pAv833tDdD4n76h4CqEZNpGdwA3V1QGWp7PK/Jfc=,tag:CcUy3rti4XcWArmHANVS8Q==,type:str]
# kind: Secret
# metadata:
# creationTimestamp: null
# name: demo
# sops:
# kms: []
# gcp_kms: []
# azure_kv:
# - vault_url: https://kv-sops-sample.vault.azure.net
# name: sops-sample-key
# version: ee44c0c0cc9e4620aa4f4c86c4942047
# created_at: "2021-08-02T20:55:40Z"
# enc: EjszDACgiDP8rW3wzs-7fAmFzlAhCq0-R9YlA9cuPcq78EXEeNTC8OnlSdXQAGdGrgE9oylu1HKZa4RB9GxzzVDav8uNVPp67NPmC4-teeA5iRE4jqlp1An6sG6CpkZGcAmKWpfj_DEWecqrNGWSLTA2hI_HKwG5xNkFh9Myik6732W-XL65IFqgepcFrNIzeHetznO0j1iISNXqMeJjeCnZ6Qq0jcXUMIfQnXjAllKfjSukiT3A3GlWxP0j50Z328t-JHi5RowYHT-hC8FDOdR_U95sqnFd27RgEXmbDIU6IGvP3vmCiZJz4YQCPXaGhySvFY6qCEoCbCSC4RaoWw
# hc_vault: []
# age: []
# lastmodified: "2021-08-02T20:55:41Z"
# mac: ENC[AES256_GCM,data:AmKRnzoImfIzPa3JBcuxUKRrse5uZwJGukpLj1wxed3R7lsUN+QAV1+WkfNyeMoW5C3ek7j20Xpbvzi+MgP8zcQOwWSwA79Svgz3hKMn9eTRTfgU+4jYezIIHCwkv61MTN8RGW5AhOInYP8oRPW3zKD+SbBO/Jeu7SC+/oVn07I=,iv:S4Th+0quL84lhJtA/lugEv+iLc+WhWEYPSlXGWKhd/M=,tag:CUGg8+UM7gNSzfjJx1Ua1w==,type:str]
# pgp: []
# encrypted_regex: ^(data|stringData)$
# version: 3.7.1
# delete encoded version of the secret
rm secret.encoded.yml
# add encrypted secret to source control and commit it
git add secret.encrypted.yml
git commit -m 'chore: add encrypted secret'
- Decrypt Kubernetes Secrets for deployment
sopsコマンドを用いて複合化ができます。
# decrypt and deploy the secret sops --decrypt secret.encrypted.yml | kubectl apply -f -
- Deploy an echo server to Kubernetes
いつものSecret同様、Pod等から参照が可能です。
apiVersion: v1
kind: Pod
metadata:
name: echo
labels:
app: echo
spec:
containers:
- image: thorstenhans/env-via-http:0.0.1
name: main
ports:
- containerPort: 5000
protocol: TCP
envFrom:
- secretRef:
name: demo
optional: true
resources:
requests:
cpu: 50m
memory: 32Mi
limits:
cpu: 100m
memory: 48Mi
Implementing traffic policies in Kubernetes (click here to source)
Kumaを使用したKubernetesのトラフィックポリシーの設計について
2つのバックエンドサービスは外部ネットワークから分離した状態で、ある1つのサービスからの通信を許可したい場合、以下のようなポリシーを適用できる。
cat <<EOF | kumactl apply -f -
type: TrafficPermission
name: api-to-backends
mesh: default
sources:
- match:
service: 'publicAPI'
destinations:
- match:
service: 'backend1'
- match:
service: 'backend2'
EOF
How to Run HAProxy with Docker (click here to source)
Dockerの実行によるパフォーマンスへの影響
Dockerを使用すると、ホストへのブリッジネットワークを作成することで、コンテナー内で実行されているサービスにアクセスできます。
よって、コンテナのローカルネットワークとホストのブリッジネットワーク間でネットワークアドレス変換（NAT）をするため、遅延が発生します。
前に引用した同じIBMの調査では、DockerのNATによって、クライアントからの100バイトの要求とアプリケーションからの200バイトの応答のレイテンシーが約35 µsから70 µsに倍増されたらしい。
非常に低いレイテンシが必要な場合は、Dockerのホストネットワーク機能の使用に切り替えることで、コンテナはホストと同じネットワークを共有できるため、NATの必要性がなくなります。
Dockerを実行する際のセキュリティに関する考慮事項
HAProxyは、80や443などの制限されたTCPポートにバインドする必要があるため、rootアクセスが必要です。
ただし、起動が完了すると、root権限が削除され、非特権ユーザーとして実行されます。
DockerでHAProxyを実行する
３つのアプリケーションを動かします。
$ sudo docker network create --driver=bridge mynetwork $ sudo docker run -d \ --name web1 --net mynetwork jmalloc/echo-server:latest $ sudo docker run -d \ --name web2 --net mynetwork jmalloc/echo-server:latest $ sudo docker run -d \ --name web3 --net mynetwork jmalloc/echo-server:latest $ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 98216bb8c5ff jmalloc/echo-server:latest "/bin/echo-server" About a minute ago Up About a minute 8080/tcp web3 ae6accc111d9 jmalloc/echo-server:latest "/bin/echo-server" About a minute ago Up About a minute 8080/tcp web2 554fafbc2b3b jmalloc/echo-server:latest "/bin/echo-server" About a minute ago Up About a minute 8080/tcp web1
HAProxyロードバランサーを介してこれらのコンテナーにトラフィックを中継できるよう、現在のディレクトリにhaproxy.cfgという名前のファイルを作成し、それに以下を追加します。
global stats socket /var/run/api.sock user haproxy group haproxy mode 660 level admin expose-fd listeners log stdout format raw local0 info defaults mode http timeout client 10s timeout connect 5s timeout server 10s timeout http-request 10s log global frontend stats bind *:8404 stats enable stats uri / stats refresh 10s frontend myfrontend bind :80 default_backend webservers backend webservers server s1 web1:8080 check server s2 web2:8080 check server s3 web3:8080 check
最初のフロントエンドはポート8404でリッスンし、HAProxy Statsダッシュボードを有効にします。このダッシュボードには、ロードバランサーに関するライブ統計が表示されます。
もう一方のフロントエンドはポート80でリッスンし、Webサーバーのバックエンドにリストされている3つのWebアプリケーションの1つに要求をディスパッチします。
以下のコマンドで、HAProxyを作成します。
$ sudo docker run -d \ --name haproxy \ --net mynetwork \ -v $(pwd):/usr/local/etc/haproxy:ro \ -p 80:80 \ -p 8404:8404 \ haproxytech/haproxy-alpine:2.4
Kubernetes CI/CD with Tekton and ArgoCD (click here to source)
TektonとArgoCDを使用してKubernetesでCI / CDプロセスを構成する方法が書かれています。
AWS App MeshとIstioの比較 (click here to source)
AWSが提供するサービスメッシュのマネージドサービスであるApp MeshとIstioの比較について書かれています。
比較項目としてはいかがあります。
OPA GatekeeperによるKubernetesセキュリティの歩き方 (click here to source)
以下のような、運用をしていく中でこういったことに注意したなどの事例を基に説明されている。
ConstraintとConstraintTemplateを何も考えずにクラスタに適用してしまうと、意図していないリソースまでも影響を受ける可能性があります。 enforcementAction: dryrunを使用し、一定期間様子を見ながら適用することをおすすめします
入門 Rancher Desktop
Rancher Desktopとは
Rancher Desktopとは、インストールして起動するだけで、Windows 10やmacOS上に簡単にKubernetes環境を展開することができるオープンソースのアプリケーションです。
Control Planeにk3s, CRIにcontainerdを用いたClusterを、
上に展開します。
Installation
では、さっそくインストールをしていきたいと思います。
踏むのは何と1stepだけです！ 以下のlink先からアプリケーションをダウンロードして起動してください。
今回、windowsを使って確認をしていきます。
起動
起動をすると、以下のようにアプリケーションが動きます。
「Kubernetes Settings」というtabを押していただき、以下のようにゲージが止まり「Reset Kubernetes」が押せる状態になると、Kubernetes Clusterの展開が完了しています。
Mac版では、リソースの指定もできます。
使い方
Kubernetes Clusterの立ち上げが完了すると、WindowsではUserディレクトリの直下にconfigファイルが生成されています。
では、Nodeの情報を見ていきます。
$ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME w10dyh79c3 Ready builder,master 17m v1.19.10+k3s1 <Internal IP> <none> Unknown 5.4.72-microsoft-standard-WSL2 containerd://1.4.4-k3s1
初期で動いているNamespace、及びPodは以下のようになっています。
$ kubectl get ns NAME STATUS AGE default Active 18m kube-system Active 18m kube-public Active 18m kube-node-lease Active 18m kube-image Active 18m $ kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-66c464876b-zt485 1/1 Running 0 18m kube-system local-path-provisioner-7ff9579c6-dzvg2 1/1 Running 0 18m kube-system metrics-server-7b4f8b595-lmsh2 1/1 Running 0 18m kube-system helm-install-traefik-zzbcw 0/1 Completed 0 18m kube-system svclb-traefik-wcg8k 2/2 Running 0 17m kube-system traefik-5dd496474-sbb4b 1/1 Running 0 17m kube-image builder-xzrlf 2/2 Running 0 17m
StorageClassに関しても、以下のように作成されます。
$ kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 18m
以下のようなmanifestを適用してみます。
$ cat pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: demo-pvc namespace: default spec: storageClassName: local-path accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 5Gi
この時点では、StorageClassのvolumeBindingModeが WaitForFirstConsumer であるため、
PodからPVCを指定されるまで、容量の確保がされないようになっています。
$ kubectl apply -f pvc.yaml persistentvolumeclaim/demo-pvc created $ kubectl get pvc -n default NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE demo-pvc Pending local-path 61s
では、このpvcを使うPodを立ち上げてみます。
apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: myfrontend image: nginx volumeMounts: - mountPath: "/var/www/html" name: mypd volumes: - name: mypd persistentVolumeClaim: claimName:
nginxが問題なく動きました。
$ kubectl apply -f nginx.yaml pod/demo-pod created $ kubectl get pods NAME READY STATUS RESTARTS AGE demo-pod 1/1 Running 0 4m22s $ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE demo-pvc Bound pvc-1222f2ff-7afd-4254-b352-640c906b5804 5Gi RWO local-path 8m28s
Appendix
k3sのバイナリは以下に配置されています。
# /mnt/c/Users/uwatsr/AppData/Local/xdg.cache/rancher-desktop/k3s /v1.19.10+k3s1/k3s -h NAME: k3s - Kubernetes, but small and simple USAGE: k3s [global options] command [command options] [arguments...] VERSION: v1.19.10+k3s1 (72e8196c) COMMANDS: server Run management server agent Run node agent kubectl Run kubectl crictl Run crictl ctr Run ctr check-config Run config check etcd-snapshot Trigger an immediate etcd snapshot help, h Shows a list of commands or help for one command GLOBAL OPTIONS: --debug (logging) Turn on debug logs [$K3S_DEBUG] --help, -h show help --version, -v print the version
Kubenews #27
2021-08-06
各タイトルを押していただくことで、実際の記事に飛びます。
Prometheus HA with Thanos Sidecar Or Receiver?
- Thanosは、次の2つの方法でPrometheusとの統合をサポートしています。
- サイドカー
- レシーバー
- Thanos Stackは以下のコンポーネントを持ちます。
- Querier
- Store
- Compactor
- Ruler
Thanos Sidecar
- 複数のプロメテウスサーバーポッドでサイドカーとして実行されます。
- このコンポーネントは、（Prometheus TSDBからの）オブジェクトストレージへのデータ配信を担当します。
- Sidecarは、Prometheusのremote read APIの上にThanosのStore APIを実装し、ThanosQuerierという名前の集中コンポーネントからPrometheusサーバーの時系列データをクエリできるようにします。
- さらに、サイドカーは、TSDBブロックを2時間間隔でオブジェクトストレージにアップロードするように構成することもできます。 この場合、バケットに保存されているデータは、Thanos Storeコンポーネントを使用してクエリできます。これは、同じStore APIを実装しており、ThanosQuerierが検出する必要があります。
Thanos Receiver
サイドカーとレシーバーの比較
- 高可用性
- プロメテウスとの統合
- ストレージ
- サイドカー
- SidecarはPrometheusのローカルストレージから読み取るため、TSDBに追加のローカルストレージ（PV）は必要ありません。
- レシーバー
- StatefulSetであるReceiverは、PVでプロビジョニングする必要があります。
- ここで必要なローカルストレージの量は、--receive.replication-factor、--tsdb.retentionというフラグに依存しています。
- このセットアップには、Sidecarと比較してより多くのローカルストレージが必要です。
- サイドカー
- データ収集
What Is Workload Security? On-Premises, Cloud, Kubernetes, and More
Announcing Vitess Arewefastyet
- Vitess arewefastyet
Scheduled-Scaling with Kubernetes HPA External Metrics
- HPA ＋ Datadogの連携について
Verify Container Image Signatures in Kubernetes using Notary or Cosign or both
-
- コンテナイメージの署名検証とtrust pinningをKubernetesクラスタに統合するためのアドミッションコントローラ
- Connaisseurは展開前のイメージ署名の確認することを目指しています。
- Mutating アドミッションコントローラーとして実装され、Kubernetesクラスターに送信されたリソースの作成または更新リクエストをインターセプトし、すべてのコンテナーイメージを識別たうえで、事前構成された公開鍵に対してそれらの署名を検証します。 その結果に基づいて、それらの要求を受け入れるか拒否します。
demo
レポジトリをクローンしてきます。
% git clone https://github.com/sse-secure-systems/connaisseur.git Cloning into 'connaisseur'... remote: Enumerating objects: 3682, done. remote: Counting objects: 100% (764/764), done. remote: Compressing objects: 100% (285/285), done. remote: Total 3682 (delta 613), reused 478 (delta 478), pack-reused 2918 Receiving objects: 100% (3682/3682), 10.01 MiB | 3.98 MiB/s, done. Resolving deltas: 100% (2198/2198), done. % cd connaisseur
Connaisseurをデプロイします。
% helm install connaisseur helm --atomic --create-namespace --namespace connaisseur NAME: connaisseur LAST DEPLOYED: Wed Aug 4 11:45:35 2021 NAMESPACE: connaisseur STATUS: deployed REVISION: 1 TEST SUITE: None % kubectl get pods -n connaisseur NAME READY STATUS RESTARTS AGE connaisseur-deployment-7d6bd95d48-bmjxw 1/1 Running 0 93s connaisseur-deployment-7d6bd95d48-ghbkf 1/1 Running 0 94s connaisseur-deployment-7d6bd95d48-m9zjh 1/1 Running 0 93s
Official Docker imagesを使ってPodを作成します。
% kubectl run hello-world --image=docker.io/hello-world pod/hello-world created
作成されたこと確認できました。
では、署名されていないimageはどうでしょう。
% kubectl run demo --image=docker.io/securesystemsengineering/testimage:unsigned Error from server: admission webhook "connaisseur-svc.connaisseur.svc" denied the request: Unable to find signed digest for image docker.io/securesystemsengineering/testimage:unsigned.
しっかり弾かれることがわかりました。
Bad Pods
- こんなものがあったので紹介です。
