Kubenews #46
2021-02-04
10 real-world stories of how we’ve compromised CI/CD pipelines (click here to source)
NCC Groupというセキュリティの会社のサイバーセキュリティコンサルティングの人が、Jenkins
とGitlab CI/CD
に対して実際にできてしまった攻撃を紹介してくれています。
Restricting cluster-admin Permissions (click here to source)
マルチユーザー/マルチテナントのKubernetesクラスターを管理している場合のRBACに関して書かれた記事になってます。
通常、クラスターの管理者には、cluster-admin
というClusterRoleが割り当てられます。
これにより、管理者はクラスター内のすべてのリソースに対してすべての操作を実行するためのアクセスとアクセス許可を得ることができます。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-admin labels: kubernetes.io/bootstrapping: rbac-defaults rules: - apiGroups: - '*' resources: - '*' verbs: - '*' - nonResourceURLs: - '*' verbs: - '*'
ここで、クラスター管理者によって実行されるアクションをブロックする必要がある場合はを考えてみます。
経緯としては、Giant Swarmで、クラスター管理者が使用するCLIの1つによって、意図したよりも多くのリソースを誤って削除するという問題が発生しましたことでした。
Giant Swarmでは、Kyvernoを利用することで、cluster-admin(および他のすべてのユーザー)が、今回の問題の原因となった特定の削除アクションの実行をブロックするクラスターポリシーを展開しました。
apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: block-bulk-certconfigs-delete annotations: policies.kyverno.io/title: Block bulk certconfig deletes policies.kyverno.io/subject: CertConfigs policies.kyverno.io/description: >- A bug in an old kubectl-gs version causes all certconfigs to be deleted on performing a login, this policy blocks that action while still allowing the single delete. spec: validationFailureAction: enforce background: false rules: - name: block-bulk-certconfigs-delete match: any: - resources: kinds: - CertConfig preconditions: any: - key: "" operator: Equals value: "" validate: message: "Your current kubectl-gs version contains a critical bug, please update to the latest version using `kubectl gs selfupdate`" deny: conditions: - key: "" operator: In value: - DELETE
まず、以下で今回のPolicyの対象を指定します。(今回は、CertConfig
というCRD)
match: any: - resources: kinds: - CertConfig
preconditions
では、リクエストに基づいて、フィルタリングをかける前提条件を設定します。
この例では、名前が指定されていないリクエスト(--all オプションなど)を対象とします。
preconditions: any: - key: "" operator: Equals value: ""
最後にPolicyにおけるアクションを指定します。
今回は、validation
を行います。
deny
を用いて、指定リソースに対する DELETE
を拒否しています。
validate: message: "Your current kubectl-gs version contains a critical bug, please update to the latest version using `kubectl gs selfupdate`" deny: conditions: - key: "" operator: In value: - DELETE
Scaling Kubernetes to Over 4k Nodes and 200k Pods (click here to source)
ワークロードの大部分はApacheMesosで実行されていたPayPalが、Kubernetes環境に移行する際に行ったパフォーマンステストに関するナレッジの共有がされています。
内容としては、スケーリング時に直面したいくつかの課題と、それらをどのように解決したかについて説明されています。
環境としては、GCPを使っています。
ワークロード
ユースケースに合わせて、指定値の変更が可能なオープンソースのワークロードジェネレーターであるk-benchを使用。
規模
各ワーカーノードには4つのCPUコアがあり、最大40のポッドを保持するようにし、約4,100ノードまでスケーリングをさせました。
ベンチマークに使用されたアプリケーションは、100ミリコアの保証されたサービス品質(QoS)において実行されるステートレスサービスでした。
最初、1,000ノードに対し2,000ポッドから始め、次に16,000ポッド、次に32,000ポッドまで増やしました。 この後、ノードを4100までスケールさせ、ポッドを150,000にし、続いて200,000ポッドまで増やしました。
これ以上のポッド数に対応するには、各ノードのコア数を増やす必要がありました。
API Server
APIサーバーへのいくつかの接続が、ローカルクライアントレベルのスロットリング(exponential backoff)に加えて、504のゲートウェイタイムアウトを返したときに、API Serverがボトルネックであることが判明しました。
Controller Manager
Controller Manager が状態をAPI Serverと同期できる速度は制限されていたので、チューニングするために以下を設定した。
- kube-api-qps — コントローラーマネージャーが特定の1秒間にAPIサーバーに対して実行できるクエリの数。
- kube-api-burst — これは、kube-api-qpsのバースト時の値.
- concurrent-deployment-syncs — デプロイメント、レプリカセットなどのオブジェクトの同期呼び出しにおける並列実行。
Scheduler
独立したコンポーネントとして独立してテストした場合、スケジューラーは1秒あたり最大1,000ポッドの高スループットレートをサポートできます。
ただし、稼働中クラスターにおけるスケジューラーでは、実際のスループット値は低下します。
etcdインスタンスが遅いと、スケジューラのバインディングレイテンシーが増加し、Pendingキューのサイズが数千ポッドに対するオーダーが発生したタイミングで増加しました。
なので、テスト中はそのオーダー数を100未満に保つようにしました。
他にも、リーダー選出のパラメータをいじって、ネットワークパーティションにおいて誤った短期間の再起動であったり、ネットワークの輻輳に対して回復力を持たせることを実施した。
etcd
Etcdをスケールさせると、多くのRaftのProposalが失敗し始めた。
GCPは100GのディスクサイズでPD-SSDディスクに対するスループットを毎秒約100MiBに抑制したことが確認できました。
現状、スループット制限を増やす方法を提供していません。
これに対し、ローカルSSDを使用することにしました。
ただ、永続的ではないため、障害が発生した場合にデータが失われる可能性がわずかに高くなりますが、スループットが非常に高くなります。
ただこれでは終わらず、SSDから期待されるパフォーマンスが得られませんでした。
これはext4ファイルシステムのwrite barrier cache commits
に起因していました。
これに対し、etcdは write-ahead logging
を使用し、raftログにコミットするたびにfsyncを呼び出すようにしました。
この場合、write barrierを無効にしても問題ありません。
この変更後、ローカルSSDの数値はPD-SSDに匹敵するように改善されました。
続いて、v1.20のetcdYAMLにLiveness Proveの下記のようなバグがあることがわかりました。
The etcd server would still restart occasionally and just a single restart can spoil the benchmark results, especially the P99 numbers.
これについては、the failure threshold count を増やすことで対処できます。
最後に、etcdのスケールアップ可能なリソース(CPU、メモリ、ディスク)を使い果たすと、etcdのパフォーマンスがrange queryによって影響を受けることがわかりました。
range queryが多く、Raftログへの書き込みが失敗すると、Etcdはうまく機能せず、クラスターのレイテンシーが遅くなります。
対応としては以下のようです。(よくわからなかったので原文を載せます)
After sharding the etcd server on the events resource, we saw an improvement in cluster stability when there is high contention of pods.
Kubenews #45
2021-01-28
Detect crashes in your Kubernetes cluster using kwatch and Slack (click here to source)
kwatchは、Kubernetes(K8s)クラスターのすべての変更を監視して、実行中のアプリのクラッシュを検出し、お気に入りのチャネル(Slack、Discordなど)に通知を公開することを目的としたオープンソースのツール。
Example
Slack のIncoming WebhookのURLを取得。
構成ファイル用のConfigmapのテンプレートの取得。
curl -L https://raw.githubusercontent.com/abahmed/kwatch/v0.3.0/deploy/config.yaml -o config.yaml
- 編集及び適用
apiVersion: v1 kind: Namespace metadata: name: kwatch --- apiVersion: v1 kind: ConfigMap metadata: name: kwatch namespace: kwatch data: config.yaml: | alert: slack: webhook: WEBHOOK_URL
kubectl apply -f config.yaml
- Slackに通知を投げるAgentの作成
kubectl apply -f https://raw.githubusercontent.com/abahmed/kwatch/v0.3.0/deploy/deploy.yaml
Tracing the path of network traffic in Kubernetes (click here to source)
この記事では、Kubernetesクラスターの内外でパケットがどのように流れるかを解説してくれています。
Kubenews #44
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, 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マニフェストもチェックできるようになった。
Kubenews #43
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
以下のような例が上がっていた。
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
Kubenews #41
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
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というものが用意されていたりする。
How Krateo PlatformOps integrates Backstage (click here to source)
Krateo PlatformOps は、あらゆるタイプのリソースを一元的に作成および管理するための、包括的でモジュール式のアーキテクチャに基づくオープンソースプロジェクトです。
幅広いオープンソースプロジェクト(現在までに900以上)の中から最高の製品を選択するために、包括的なダッシュボードからそれらを管理し、一元的に調整可能なテンプレートを開発できる。
サービスカタログ的な感じかも。
以下がコンポーネントになる。
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)
勉強になりそうなので、載せました。
後日読もうと思います。
Kubenews #35
2021-10-15
How to Start your Cloud Security Journey (click here to source)
クラウドセキュリティの旅を始める上で重要な重点分野のいくつかは次のとおりです。
脅威モデリング
脅威モデリングは、脅威を特定し、システムへの脅威を防止または軽減するための対策を定義するプロセスです。
脅威のモデリングに関連する手順:
- アーキテクチャ図を作成する
- 脅威を特定する
- 軽減する
- 検証
セキュリティ設定ミスの修正
このレポートによると、クラウドの脆弱性の95%以上がクラウドの構成ミスに関連しています。
Prowler
Prowlerは、AWSのみに対応しており、クラウドセキュリティの設定ミスを特定するのに役立つオープンソースのセキュリティ監査ツールです。
主な機能として、クラウドアカウントのセキュリティの脆弱性のリストを提供します。
調査結果をHTML、CSV、JSON、またはjson-asff形式でエクスポートできます。
Prowlerは、AWS Security Hubと統合することが可能です。
Security Hubを使用すると、Prowlerだけでなく、AWS GuardDuty、Inspector、Macieなどの複数のAWSサービスからのセキュリティアラートまたは検出結果を集約、整理、および優先順位付けすることが可能です。
ネットワークアクセス
クラウド環境のアーキテクチャを評価するには、ネットワーク図が必要です。
CloudMapper
CloudMapperは、アマゾンウェブサービス(AWS)環境の分析に役立ちます。
ネットワーク図の作成を支援し、ブラウザに表示します。
ネットワークセグメンテーション
ネットワークセグメンテーションを実装することにより、ネットワークの攻撃対象領域を減らします。
フェイルオープンではなく、フェイルセーフネットワークアクセスアプローチを採用することを検討してください。
- フェイルセーフ
- 操作方法を間違ったり、部品が壊れたり、誤作動したりした場合に、危ない方向ではなく、安全な方向へ向かうように設計すること
クラウドリソースへのアクセスの改善
クラウドリソースへの接続には、安全でプライベートなアクセスが必要です。
これを実現するために様々な方法があります。
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は、ユーザーを直接管理または認証をせず、認証エンドポイントを構成でき、認証エンドポイントは、認証プロバイダーによって管理されます。
Kubenews #33
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ノードに多数のリクエストが送信されないようにしました。