2022-01-21

Kubenews #44

kubenews

2021-01-21

How to Monitor Endpoints in Kubernetes using Blackbox Exporter (click here to source)

WhiteBox vs BlackBox monitoring

ホワイトボックスの監視とは、アプリケーションログ、ハンドラーからのメトリックなど、システムの内部を監視することです。

ブラックボックスの監視には、サーバーのダウン、ページが機能しない、サイトのパフォーマンスの低下など、ユーザーに影響を与える外部からの動作の監視が含まれます。

What is Blackbox Exporter?

Blackbox Exporterは、HTTPS、HTTP、TCP、DNS、ICMPなどのエンドポイントをプローブするために使用されます。

エンドポイントを定義した後、BlackboxExporterはGrafanaなどのツールを使用して視覚化できるメトリックを生成します。

Install

$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
$ helm repo update
$ helm install prometheus-blackbox prometheus-community/prometheus-blackbox-exporter -f values.yaml

Metrics

以下のようなメトリクスが取得できます。

メトリック名	関数
probe_duration_seconds	プローブが完了するまでにかかった時間を秒単位で返します
probe_http_status_code	応答HTTPステータスコード
probe_http_version	プローブ応答のHTTPのバージョンを返します
probe_success	プローブが成功したかどうかを表示します
probe_dns_lookup_time_seconds	プローブDNSルックアップにかかった時間を秒単位で返します
probe_ip_protocol	プローブIPプロトコルがIP4またはIP6のどちらであるかを指定します
probe_ssl_earliest_cert_expiryメトリック	unixtimeで最も早いSSL証明書の有効期限を返します
probe_tls_version_info	使用されるTLSバージョンが含まれています
probe_failed_due_to_regex	正規表現が原因でプローブが失敗したかどうかを示します
probe_http_content_length	HTTPコンテンツ応答の長さ
probe_http_version	プローブ応答のHTTPのバージョンを返します

用途の例としては以下などがある。

probe_http_duration_secondsメトリックを使用して応答時間を測定することで、Webサイトのパフォーマンスを監視し、サービスAとBの遅延の原因となった外部ターゲットの急増を探すことができる
probe_ssl_earliest_cert_expiryメトリックを使用して、ドメイン証明書の有効期限がいつ切れるのかを監視する
probe_http_status_codeメトリックを使用して、/ healthエンドポイントでポッドをプローブする

Continuous Profiling in Kubernetes Using Pyroscope (click here to source)

What is profiling?

プロファイリングは、メモリ、プログラムの時間計算量、または関数呼び出しの頻度と期間を測定するプログラム分析です。

プロファイリングツールを使用してアプリケーションのコードを調べると、パフォーマンスのボトルネックを見つけて修正するのに役立ちます。

Continuous profiling

Pyroscope
Parca
datadog
google cloud profiler

比較について書いてくれた記事もある。

Pyroscope, datadog, google cloud profilerの比較

Pyroscopeは、データの保存とクエリの両方を可能な限り効率的に行うためにデータをプロファイリングするために特別に構築されたストレージエンジンの構築に重点を置いています。

エージェントサーバーモデルを使用して、アプリケーションからPyroscopeサーバーにプロファイルを送信します。

Pyroscopeは言語固有のプロファイラーとeBPFプロファイリングの両方をサポートしています。

一方、Parcaは少し異なるアプローチを取り、現状はC、C ++、Goなどのコンパイル言語に対してのみeBPFを用いてプロファイリングする。

How to install Pyroscope?

$ helm repo add pyroscope-io https://pyroscope-io.github.io/helm-chart

$ helm install pyroscope pyroscope-io/pyroscope --set service.type=NodePort

そのほか、「Integrating Google microservices demo with Pyroscope」というデモについても説明があるので、ぜひ試してみてください。

Securing a Kubernetes pod with Regula and Open Policy Agent (click here to source)

regulaについて

Regulaは、TerraformファイルとCloudFormationファイルのセキュリティとコンプライアンス違反をチェックできるだけでなく、KubernetesYAMLマニフェストもチェックできるようになった。

2022-01-14

Kubenews #43

kubenews

2022-1-14

Zarf (click here to source)

Air gapというAir gapサーバーなどをかませて、インターネットとLANを隔離しているような環境でKubernetes Clusterを容易に構築するためのものらしい。

ここを見る限り、zarf initを叩くだけでkubernetesが動いてそう。

Improving Application Availability with Pod Readiness Gates (click here to source)

場合によっては、Liveness ProveやReadiness ProveをPodに対して適用できる状態では無かったり、より複雑なreadinessチェックをしたい場合にどうすれば良いかという問いに対して、Readiness Gateがあるよというお話。

設定としては以下のように定義を追加するだけ。

kind: Pod
...
spec:
  readinessGates:
    - conditionType: "www.example.com/some-gate-1"

これをapplyすると、このPodをdescribeすると以下のように表示される。

...
Conditions:
  Type                          Status
  www.example.com/some-gate-1   False
  Initialized                   True
  Ready                         False
  ContainersReady               True
  PodScheduled                  True

以下のような例が上がっていた。

qiita.com

PodとしてはReadyになっているものの、Readuness Gateで設定されたものがTrueにされるまで、ServiceのEndpointに配置されないというものである。

ここのパラメータは、kubectl patch などでは変更できないため、kubectl proxy をして、curlを用いて直接APIを叩く必要がある。

Hello youki! (click here to source)

Rustで書かれたOCI Runtimeであるyoukiについて書かれている。

ちょっとしたベンチマークの情報なども載っている。

BumbleBee: Build, Ship, Run eBPF tools (click here to source)

Bumblebeeは、eBPFプログラムのパッケージ化、配布、およびユーザースペースコードの自動生成に重点を置いています。

initコマンドは、ビルドする予定のeBPFプログラムについていくつかの設定を行うようなリクエストをして、コードテンプレートを自動生成します。この時点で、カーネルに必要な機能を実装するために必要なeBPFコードを追加できます。

bee init

buildで、OCIパッケージのeBPFイメージが作成され、ワークフローに配置し、環境にデプロイできます。

bee build <initで作成したファイル名> my_probe:v1

runをすることで、プログラムを実行出来ます。

bee run my_probe:v1

Minecraft as a k8s admin tool (click here to source)

すごい昔の記事だが、面白そうなので紹介します。

豚はPod
牛はReplicaSets
鶏はService
馬はDeployment

2021-12-17

Kubenews #41

kubenews

2021-12-17

Where are my container's files? Inspecting container filesystems (click here to source)

Method 1: Exec into the container

コンテナのファイルシステムを調べる方法をいち早く知りたいのであれば、一般的な解決策はDockerコマンドを使用することである。

docker exec -it mycontainer /bin/bash

ただし、このアプローチの欠点の1つは、コンテナ内にシェルが存在する必要があることです。

コンテナ内に/bin/bash、 /bin/shまたは他のシェルが存在しない場合、このアプローチは機能しません

Method 2: Using nsenter

次のようなnsenterコマンドを使用して、ターゲットのコンテナがいる名前空間に入ることができます。

# Get the host PID of the process in the container
PID=$(docker container inspect mycontainer | jq '.[0].State.Pid')

# Use nsenter to go into the container’s mount namespace.
sudo nsenter -m -t $PID /bin/bash

これは、ターゲットであるプロセス(-t $PID)のmount (-m) namespaceに入り、/bin/bash を実行します。

このアプローチは、docker execアプローチよりも有望に見えるかもしれませんが、同様の/bin/bash問題が発生します。

ターゲットコンテナー内に（または他のシェルが）存在する必要があります。

Method 3: Copy with docker

上記の問題に対する別のアプローチは、関連するファイルをホストにコピーしてから、そのコピーを操作することです。

実行中のコンテナから選択したファイルをコピーするには、次を使用できます。

docker cp mycontainer:/path/to/file file

次の方法でファイルシステム全体のスナップショットを作成することもできます。

docker export mycontainer -o container_fs.tar

Method 4: Finding the filesystem on the host

ホストから直接コンテナのファイルシステムにアクセスしたいと思った際に、コンテナのファイルはホストのファイルシステムのどこかにあるはずですが、どこにあるのでしょうか？

Dockerのinspectコマンドには、次のような手がかりがあります。

docker container inspect mycontainer | jq '.[0].GraphDriver'

{
  "Data": {
    "LowerDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab-init/diff:/var/lib/docker/overlay2/524a0d000817a3c20c5d32b79c6153aea545ced8eed7b78ca25e0d74c97efc0d/diff",
    "MergedDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/merged",
    "UpperDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/diff",
    "WorkDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/work"
  },
  "Name": "overlay2"
}

LowerDir：最後のレイヤーを除く、コンテナー内のすべてのレイヤーのファイルシステムが含まれます
UpperDir：コンテナの最上位層のファイルシステム。これは、実行時の変更が反映される場所でもあります。
MergedDir：ファイルシステムのすべてのレイヤーを組み合わせたビュー。
WorkDir：ファイルシステムの管理に使用される内部作業ディレクトリ。

したがって、コンテナ内のファイルを確認するには、MergedDirパスを確認するだけです。

sudo ls /var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/merged

Method 5: /proc/[pid]/root

ホストからコンテナのファイルシステムを見つけるさらに簡単な方法があります。コンテナ内のプロセスのホストPIDを使用すると、次の操作を実行できます。

sudo ls / proc / [pid]/ root

Linuxは、プロセスのマウント名前空間を表示します。

Bonus: /proc/[pid]/mountinfo

方法4で説明したコンテナのオーバーレイファイルシステムに関するすべての情報は、Linux/procファイルシステムから直接検出することもできます。

/proc/<pid>/mountinfoを単に見ると、次のようなものが表示されます。

2363 1470 0:90 / / rw,relatime master:91 - overlay overlay rw,lowerdir=/var/lib/docker/overlay2/l/YZVAVZS6HYQHLGEPJHZSWTJ4ZU:/var/lib/docker/overlay2/l/ZYW5O24UWWKAUH6UW7K2DGV3PB,upperdir=/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/diff,workdir=/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/work
2364 2363 0:93 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
2365 2363 0:94 / /dev rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755,inode64
…

ここでは、コンテナがルートとしてオーバーレイファイルシステムをマウントしていることがわかります。

Horizontal Pod Autoscaling with Custom Metrics in Kubernetes (click here to source)

自動スケーリングに選択する最適なメトリックは、アプリケーションによって異なります。

コンテキストに応じて役立つ可能性のあるメトリックのリストは以下の通りです。

CPU
メモリー
リクエストスループット（HTTP、SQL、Kafka…）
平均、P90、またはP99リクエストのレイテンシ
ダウンストリーム依存関係のレイテンシ
アウトバウンド接続の数
特定の機能のレイテンシ
キューの深さ
保持されているロックの数

Kubernetesでの自動スケーリング

Kubernetesでの自動スケーリングデプロイのオプションについて詳しく説明しましょう。Kubernetesは、ポッドに対して2種類の自動スケーリングを提供します。

水平ポッド自動スケーリング（HPA）: 展開内のポッドの数を自動的に増減します。
垂直ポッド自動スケーリング（VPA）: デプロイメント内のポッドに割り当てられたリソースを自動的に増減します。

標準的なHPAのmanifestは以下の通り。

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-cpu-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

それに対し、カスタムメトリックを用いる場合以下のようになります。

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-custom-metric-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: my-custom-metric
      target:
        type: AverageValue
        averageUtilization: 20

metric[].pods.metric.nameでカスタムメトリック名を指定しているのがわかります。

Kubernetes Custom Metric API

Kubernetesがカスタムメトリックにアクセスするには、メトリックの提供を担当するカスタムメトリックサーバーを作成する必要があります。

フレームワークとして用意されたインターフェースを載せたGoサーバーを実装するだけで済みます。

type CustomMetricsProvider interface {
    // Fetches a single metric for a single resource.
    GetMetricByName(ctx context.Context, name types.NamespacedName, info CustomMetricInfo, metricSelector labels.Selector) (*custom_metrics.MetricValue, error)

    // Fetch all metrics matching the input selector, i.e. all pods in a particular namespace.
    GetMetricBySelector(ctx context.Context, namespace string, selector labels.Selector, info CustomMetricInfo, metricSelector labels.Selector) (*custom_metrics.MetricValueList, error)

    // List all available metrics.
    ListAllMetrics() []CustomMetricInfo
}

Prometheusなどは、Prometheus adapterというものが用意されていたりする。

qiita.com

How Krateo PlatformOps integrates Backstage (click here to source)

Krateo PlatformOps は、あらゆるタイプのリソースを一元的に作成および管理するための、包括的でモジュール式のアーキテクチャに基づくオープンソースプロジェクトです。

幅広いオープンソースプロジェクト（現在までに900以上）の中から最高の製品を選択するために、包括的なダッシュボードからそれらを管理し、一元的に調整可能なテンプレートを開発できる。

サービスカタログ的な感じかも。

以下がコンポーネントになる。

フロントエンドダッシュボード
- それはバックエンドに渡されるすべての要求されたフィールドを充填する形から開始する（コンポーネント名、説明、所有者、APIのURLなど）
バックエンドスペース
- 情報はテンプレートを埋めるために使用され、Gitのリポジトリに保存されます
Krateo Runtime (ArgoCD)
- ツールはGitリポジトリと同期し、マニフェストファイルに記述されているリソースの作成を処理します。
- gitリポジトリで行われたすべての変更は、リソースの変更を生成し、すべての変更の履歴を作成します。

kube-lineage: A CLI tool for visualizing Kubernetes object relationships (click here to source)

kube-lineageは、Kubernetesオブジェクトの関係を視覚化するためのCLIツールです。

krewプラグインマネージャーを使用して、kube-lineageをkubectlプラグインとしてインストールできます。

kubectl krew install lineage

実際の可視化は以下の通り。

$ kubectl lineage clusterrole/system:metrics-server
NAMESPACE     NAME                                                     READY   STATUS    AGE
              ClusterRole/system:metrics-server                        -                 5m
              └── ClusterRoleBinding/system:metrics-server             -                 5m
kube-system       └── ServiceAccount/metrics-server                    -                 5m
kube-system           ├── Pod/metrics-server-7b4f8b595-8m7rz           1/1     Running   5m
kube-system           │   └── Service/metrics-server                   -                 5m
                      │       ├── APIService/v1beta1.metrics.k8s.io    True              5m
kube-system           │       └── EndpointSlice/metrics-server-wb2cm   -                 5m
kube-system           └── Secret/metrics-server-token-nqw85            -                 5m
kube-system               └── Pod/metrics-server-7b4f8b595-8m7rz       1/1     Running   5m

helmにも対応をしているらしい。

$ RELEASE_NAME="kube-state-metrics"
$ kubectl lineage helm $RELEASE_NAME --depth=1
NAMESPACE    NAME                                                  READY   STATUS     AGE
monitoring   kube-state-metrics                                    True    Deployed   5m
             ├── ClusterRole/kube-state-metrics                    -                  5m
             ├── ClusterRoleBinding/kube-state-metrics             -                  5m
monitoring   ├── Deployment/kube-state-metrics                     1/1                5m
monitoring   ├── Secret/sh.helm.release.v1.kube-state-metrics.v1   -                  5m
monitoring   ├── Service/kube-state-metrics                        -                  5m
monitoring   └── ServiceAccount/kube-state-metrics                 -                  5m

How eBPF will solve Service Mesh - Goodbye Sidecars (click here to source)

勉強になりそうなので、載せました。

後日読もうと思います。

2021-10-15

Kubenews #35

kubenews

2021-10-15

How to Start your Cloud Security Journey (click here to source)

クラウドセキュリティの旅を始める上で重要な重点分野のいくつかは次のとおりです。

脅威モデリング
セキュリティの設定ミスの修正
ネットワークアクセス
クラウドリソースへのアクセスの改善
IAMポリシーの保護
ロギングとモニタリングの実装

脅威モデリング

脅威モデリングは、脅威を特定し、システムへの脅威を防止または軽減するための対策を定義するプロセスです。

脅威のモデリングに関連する手順：

アーキテクチャ図を作成する
脅威を特定する
- STRIDEやPASTAなどの脅威モデリング手法が有用。
軽減する
検証

セキュリティ設定ミスの修正

このレポートによると、クラウドの脆弱性の95％以上がクラウドの構成ミスに関連しています。

Prowler

Prowlerは、AWSのみに対応しており、クラウドセキュリティの設定ミスを特定するのに役立つオープンソースのセキュリティ監査ツールです。

主な機能として、クラウドアカウントのセキュリティの脆弱性のリストを提供します。

調査結果をHTML、CSV、JSON、またはjson-asff形式でエクスポートできます。

Prowlerは、AWS Security Hubと統合することが可能です。

Security Hubを使用すると、Prowlerだけでなく、AWS GuardDuty、Inspector、Macieなどの複数のAWSサービスからのセキュリティアラートまたは検出結果を集約、整理、および優先順位付けすることが可能です。

ネットワークアクセス

クラウド環境のアーキテクチャを評価するには、ネットワーク図が必要です。

CloudMapper

CloudMapperは、アマゾンウェブサービス（AWS）環境の分析に役立ちます。

ネットワーク図の作成を支援し、ブラウザに表示します。

ネットワークセグメンテーション

ネットワークセグメンテーションを実装することにより、ネットワークの攻撃対象領域を減らします。

フェイルオープンではなく、フェイルセーフネットワークアクセスアプローチを採用することを検討してください。

フェイルセーフ
- 操作方法を間違ったり、部品が壊れたり、誤作動したりした場合に、危ない方向ではなく、安全な方向へ向かうように設計すること

クラウドリソースへのアクセスの改善

クラウドリソースへの接続には、安全でプライベートなアクセスが必要です。

これを実現するために様々な方法があります。

VPNセットアップ
bastion/Jump Box
KeycloakやTeleportなどの中央認証システム
AWS SSM

IAMポリシーの保護

ユーザーアクセスポリシー（IAMポリシー）は、クラウドインフラストラクチャを保護するのに役立つもう1つのコアコントロールです。

IAMポリシーの周囲に適切なセキュリティ衛生を設けることで、違反が発生した場合に攻撃者が広範囲の損害を与える可能性を減らすことができます。

実装を検討する必要があるいくつかのIAMコントロール：

クラウドアカウントのrootユーザーアクセスキーをロックする
個々のIAMユーザーを作成する
ユーザーグループを使用して、IAMユーザーにアクセス許可を割り当てます
最小特権を付与する
ユーザーに強力なパスワードポリシーを構成する
MFAを有効にする
Roleを使用して権限を委任する
アクセスキーを共有しない
クレデンシャルを定期的にローテーションする
不要なクレデンシャルを削除する
クラウドアカウントのアクティビティを監視する

policy_sentryなどのツールを使用して、最小特権のIAMポリシーを作成することもできます。

セキュリティのログ記録と監視

セキュリティのログ記録と監視は、クラウド環境で何が悪かったのかを特定するのに役立ち、悪意のあるイベントを発見できる唯一の方法です。

手始めに、少なくともすべてのリージョンでCloudtrailを有効にして、クラウドストレージに配置することができます。

次に、複数の認証の拒否や特権の昇格の失敗など、一般的なセキュリティのユースケースに対してアラートを設定する必要があります。

APIコールログ（Cloudtrail）、DNSログ（Route53）、ネットワークアクセスログ（VPCフローログ）、クラウドストレージログ（S3）、Security Hub、GuardDuty、WAFログ、アプリケーションログなどのセキュリティサービスログは、検出ルールを構築するためにログに記録する必要があります。

長期保存用に個別のログアカウントを持ち、一元化された監視アカウントを持ち、ElasticsearchなどのSIEMにデータを送信することをお勧めします。

micro-lc: a new open-source project for micro frontend orchestration (click here to source)

マイクロフロントエンド：それらは何であり、何のために必要ですか？

アプリケーションの開発を簡素化および高速化できることから人気が高まっているマイクロサービスのアーキテクチャパターンと同じようなものとして、マイクロフロントエンドが生まれ、マイクロサービスがバックエンドに対して実行するのと同様のデカップリングロジックをフロントエンドに適用します。

これにより、フロントエンドアプリケーションを一連の再利用可能なモジュラーコンポーネントに分解することや、新しいフロントエンド機能リリースの敏捷性を向上させることができます。

micro-lc：特性と利点

micro-lcは、Mia‑Platformによって作成されたマイクロフロントエンドオーケストレーションのコンポーネントであり、開発エクスペリエンスの一貫性を保つことができます。

すべてのバックエンドとフロントエンドのパーツが含まれており、プラグインを介してそれらを拡張できます。

フロントエンド

フロントエンドは、各々が接続されたフロントエンドを構成するために使用することができる一連のクロスアプリケーション機能を提供するContainerから構成されます。

機能としては以下のようなものがあります。

レイアウトの基本要素、
- トップバーとメニュー（サイドバーメニュー、折りたたみ可能なサイドバーメニュー、トップバーメニューの3種類）
アプリケーションの色
ロゴとファビコン
ウィンドウタイトル
ダークモード/ライトモード
ユーザーデータ
グーグルアナリティクス
プラグイン管理

バックエンド

バックエンドでは、フロントエンドの要素を定義する要素、ユーザー認証、また一般的な構成を管理できます。

micro-lcは、ユーザーを直接管理または認証をせず、認証エンドポイントを構成でき、認証エンドポイントは、認証プロバイダーによって管理されます。

2021-10-01

Kubenews #33

kubenews

2021-10-01

IAM roles for Kubernetes service accounts - deep dive (click here to source)

「ServiceAccountのCredentialを用いて、Podの中からAWSのサービスにアクセスする方法」に関して、OpenID Connectの例を交えながら説明してくれている記事です。

Top Open Source CI/CD Tools for Kubernetes to Know (click here to source)

Open SourceのCI/CDツールの中で、人気なツールを選抜してPros＆Consを交えながら紹介してくれています。

Tekton
Argo
GitHub Actions
Jenkins X
OpenShift Pipelines
Spinnaker
Circle CI
GitLab CI

How Chaos Mesh helps Apache APISIX improve system stability (click here to source)

Apache APISIX (github)というAPI Gatewayを用いた環境において、Chaos mesh (github)を用いてシステムの安定性を向上させる方法が紹介されています。

課題

Apache APISIXは、1日に数百億のリクエストを処理します。

その中で気づいた課題が以下の2点でした。

Apache APISIXの構成センターで、etcdとApache APISIXの間で予期しない高いネットワーク遅延が発生した場合でも、Apache APISIXはトラフィックを正常にフィルタリングして転送できるのだろうか。
etcdクラスター内のノードに障害が発生し、クラスターが引き続き正常に実行できる場合においても、ノードとApache APISIX管理APIとのインタラクションに関するエラーが報告されてしまう。

Apache APISIXは、ユニット、エンドツーエンド（E2E）、および継続的インテグレーション（CI）でのテストを通じて多くのシナリオをカバーすることができました。

ただ、外部コンポーネントとの相互作用シナリオはカバーしていません。

ネットワークがジッターしたり、ハードディスクに障害が発生したり、プロセスが強制終了したりした場合など、システムが異常に動作する場合、Apache APISIXは適切なエラーメッセージを表示できますか？実行を継続することはできますか、それとも通常の操作に戻すことができますか？ということを検証しきれていませんでした。

カオスメッシュを選んだ理由

Chaos Meshは、クラウドネイティブなChaos Engineeringプラットフォームであり、Kubernetes上の複雑なシステム向けのオールラウンドなフォールトインジェクション手法を備えており、ポッド、ネットワーク、ファイルシステム、さらにはカーネルのフォールトをカバーします。

この機能によって、ユーザーがシステムの弱点を見つけるのに役立つ上に、システムが実稼働環境において制御不能な状況になった際の対応ができるようになります。

APISIX配下でカオスメッシュを使用する方法

前述の2つの課題に対する。

課題1

次の手順を使用して、カオスエンジニアリング実験を展開しました。

[1]

ApacheAPISIXが正常に実行されているかどうかを測定するためのメトリックが見つけることができました。

Grafanaを使用してApacheAPISIXの実行中のメトリックを監視した。

比較のために、CIにおいてPrometheusからデータを抽出しました。

ここでは、1秒あたりのルーティングおよび転送要求（RPS）とetcd接続を評価メトリックとして使用しました。

加えてログを分析しました。

Apache APISIXの場合、Nginxのエラーログをチェックして、エラーが発生したかどうか、およびエラーが予想どおりであったかどうかを判断しました。

[2]

Control Groupにおける試験を行いました。

私たちはcreate route と access routeの両方が成功していること、そしてetcdに接続することができるというのがわかりました。

そしてRPSを記録しました。

[3]

ネットワークカオスを使用して5秒のネットワーク遅延を追加し、再テストしました。

今回、 set routeが失敗し、 get routeが成功でき、etcdに接続でき、RPSは前の実験と比較して大きな変化はないという結果でした。

実験は私たちの期待に沿う形となった。

課題2

上の検証をした際に、ポッドキルカオスを導入して、予想されるエラーを再現しました。

クラスタ内の少数のetcdノードをランダムに削除したところ、APISIXがetcdに接続できる場合と接続できない場合があり、ログに多数の接続拒否エラーが出力されました。

etcdエンドポイントリストの最初または3番目のノードを削除すると、set route に対して正常な結果が返されたのに対し、リストの2番目のノードを削除すると、set route に対して「接続が拒否されました」というエラーが返されました。

原因としては、Apache APISIXで使用されるetcd Lua APIが、ランダムではなく順次エンドポイントを選択していました。

結果としてetcdクライアントを作成した際に、1つのetcdエンドポイントのみにバインドされてしまい、これが継続的な失敗につながりました。

対応として、etcd Lua APIにヘルスチェックを追加して、切断されたetcdノードに多数のリクエストが送信されないようにしました。

2021-09-24

Kubenews #32

kubenews

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
- SELinuxによるaccess controls
- Seccomp (secure computing mode)を用いたsystem callsを制御するためのkernel facilities
- cgroupによるCPU, memoryやそのたリソースの隔離.
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プロセスで構成を適切に管理することは、セキュリティを強化できます。
  - 変更管理の改善
  - 攻撃対象領域を減らす可能性のある構成上の欠陥の特定
  - 説明責任と改善の機会を高めるための署名や作成者の追跡
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）をリリースしました。

Kubernetes Hardening Guidance

この記事は、以下の三つに関して書かれている。

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
- JDBCとODBCのインターフェイスを使用してSparkに接続するためのもの。
  - ODBC: RDBMSにアクセスするための共通インタフェース (API)
  - JDBC: Java とリレーショナルデータベースの接続のためのAPI
- Beeline や Tableau などの外部のクライアントから Spark に接続する際に使われます。
trino (github)
- 高速な分散SQLクエリエンジン
redash
- オープンソースで提供されているダッシュボード作成ツール
jupyterhub
- ブラウザからアクセス/実行できるユーザ認証機能つきJupyterサーバー
kafka

DataRoasterデモ

www.youtube.com

7 Microservices Best Practices for Developers (click here to source)

マイクロサービスのメリットと課題

メリット
- デプロイとスケーリングの高速化
  - アプリケーションドメインの責任が小さいほど自動化が可能になり、展開とスケーリングが高速化されます。
- ダウンタイムの削減
  - 1つの利用できないサービスが主要なビジネス機能に与える影響を制限し、ビジネス全体の稼働時間を改善できる。
- 可用性の確保
  - インスタンスがダウンしたときの影響を制限できる。
課題
- サービス間通信
  - モノリスアーキテクチャからマイクロサービスアプリケーションに関数を抽出すると、かつては内部関数呼び出しであったものが、その外部マイクロサービスの認証と承認を必要とする外部API呼び出しになります。
- セキュリティレイヤー
  - モノリスアプリケーションでの認証と承認は、エントリの時点で1回処理できます。
  - マイクロサービスへの移行に伴い、すべてのマイクロサービスは、アクセス制御を実施するために何らかの認証と承認を実行する必要があります。
- スケーラビリティ
  - マイクロサービスを使用すると、独立した機能をすばやく拡張できますが、これを効果的に行うには、優れたアプリ管理とさらに優れたツールが必要です。

マイクロサービスのベストプラクティス

1.小さなアプリケーションドメイン

マイクロサービス戦略を採用するには、単一責任の原則を採用する必要があります。

単一のサービスに対する責任の範囲を制限することにより、そのサービスの失敗による悪影響を制限します。

2.データストレージの分離

同じデータベースに接続する複数のマイクロサービスは、本質的には依然としてモノリシックアーキテクチャです。

モノリスは、アプリケーション層ではなくデータベース層にあるため、同じように壊れやすくなっています。各マイクロサービスには、可能な限り、独自のデータ永続化レイヤーが必要です。

これにより、他のマイクロサービスからの分離が保証されるだけでなく、特定のデータセットが使用できなくなった場合の爆風半径が最小限に抑えられます。

ファイルストアについても同様のケースを作成できます。

マイクロサービスアーキテクチャを採用する場合、同じファイルストレージサービスを使用するために個別のマイクロサービスを用意する必要はありません。

ファイルの実際の重なりがない限り、個別のマイクロサービスには個別のファイルストアが必要です。

3.通信チャネル

マイクロサービスが相互に通信する方法、特に関心のあるイベントに関しては、慎重に検討する必要があります。

そうしないと、単一の利用できないサービスが通信障害につながり、アプリケーション全体が崩壊する可能性があります。

マイクロサービス間の通信には、同期と非同期の2種類があります。

マイクロサービス間の同期通信では、チェーン内のリンクが切断されると機能しなくなってしまう依存関係チェーンが作成される可能性があります。

一方非同期通信では、サービスは要求を送信し、応答を待たずにその存続期間を継続します。

非同期通信への単純ですが効果的なアプローチは、パブリッシュ/サブスクライブパターンを採用することです。

対象のイベントが発生すると、プロデューサー（この場合はマイクロサービス）はそのイベントのレコードをメッセージキューサービスに公開します。

そのタイプのイベントに関心のある他のマイクロサービスは、そのイベントのコンシューマーとしてメッセージキューサービスにサブスクライブします。

4.互換性

可能な限り、下位互換性を維持して、コンシューマーが壊れたAPIに遭遇しないようにします。

一般的な方法は、/api/v1または/api/v2のようなパスレベルの互換性保証に従うことです。

後方互換性のない変更は、/api/v3のような新しいパスに移動します。

5.マイクロサービスのオーケストレーション

マイクロサービスのオーケストレーションは、プロセスとツールの両方で成功するための重要な要素です。

技術的には、systemdやDocker、podmanなどを使用して仮想マシンでコンテナーを実行できますが、コンテナーオーケストレーションプラットフォームと同じレベルの復元力は提供されません。

効果的なマイクロサービスオーケストレーションのために、バトルテスト済みのコンテナオーケストレーションプラットフォームに依存することをお勧めします。その分野の明確なリーダーはKubernetesです。

6.マイクロサービスのセキュリティ

セキュリティポリシーを適用するための一元化されたシステムは、悪意のあるユーザー、侵入型ボット、および欠陥のあるコードからアプリケーション全体を保護するために不可欠です。

7.メトリクスとモニタリング

(省略)

2021-09-17

Kubenews #31

kubenews

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）を使用する方法について書かれています。