kakakakakku blog

Weekly Tech Blog: Keep on Learning!

Flux v2 で Image Ops を実現する「自動イメージ更新機能」を試した

GitOps ソフトウェアの Flux v1 にはイメージレジストリを監視してイメージタグを自動的に最新化する「Automate image updates(自動イメージ更新)機能」が組み込まれている.別名で「Image Ops」と言ったりもする.具体的には Deployment YAML などの annotationsfluxcd.io/automated: "true" を設定すると有効化できていた.

現在使われている Flux v2 にも「Automate image updates(自動イメージ更新)機能」は組み込まれている.しかし Flux v1 と互換性はなく,完全に異なる仕組みになっている.今回は以下のドキュメントを参考にしながら Flux v2「Automate image updates(自動イメージ更新)機能」を試していく!

fluxcd.io

fluxcd.io

環境

今回は kubeadm を使って構築した Kubernetes v1.23.1 クラスタを使う.

  • Kubernetes v1.23.1

全体構成

全体構成をまとめておく.まず,Flux v2「Automate image updates(自動イメージ更新)機能」CRD (Custom Resource Definitions) を使う.以下の2種類のコントローラーでイメージレジストリを監視したり,GitHub リポジトリを更新したりする.そして ImageRepository ImageUpdateAutomation などの CRD も組み合わせて使う.公式ドキュメントから引用した図がわかりやすい!

  • Image Reflector controller(イメージレジストリを監視する)
  • Image Automation controller(Git リポジトリを更新する)

Image reflector and automation controllers より引用

Flux CLI をセットアップする

準備として Flux CLI をセットアップしておく.さらに今回使う代表的なサブコマンドも以下にまとめておく.

$ curl -s https://fluxcd.io/install.sh | sudo bash
$ flux --version
flux version 0.28.5

fluxcd.io

Flux v2 をセットアップする

最初は Kubernetes クラスタに Flux v2 をセットアップする.flux bootstrap github コマンドを使うと Flux v2 のセットアップと Flux の設定を管理する GitHub リポジトリを自動的に作れる.今回はドキュメントの通りに GitHub リポジトリ flux-image-updates を使うことにする.セットアップをするときは既に紹介した「Automate image updates(自動イメージ更新)機能」のコントローラもセットアップする必要があるため --components-extra=image-reflector-controller,image-automation-controller オプションも追加する.

  • image-reflector-controller(イメージレジストリを監視する)
  • image-automation-controller(Git リポジトリを更新する)
$ export GITHUB_USER=kakakakakku

$ flux bootstrap github \
  --components-extra=image-reflector-controller,image-automation-controller \
  --owner=${GITHUB_USER} \
  --repository=flux-image-updates \
  --branch=main \
  --path=clusters/my-cluster \
  --read-write-key \
  --personal

セットアップ後に確認すると flux-system Namespace にコントローラが起動されていた.

$ kubectl get pod image-reflector-controller-86db8b6f78-n62lf -n flux-system
NAME                                          READY   STATUS    RESTARTS   AGE
image-reflector-controller-86db8b6f78-n62lf   1/1     Running   0          10m

$ kubectl get pod image-automation-controller-77fd9657c6-7ft2m -n flux-system
NAME                                           READY   STATUS    RESTARTS   AGE
image-automation-controller-77fd9657c6-7ft2m   1/1     Running   0          10m

そして,自動的に作られた GitHub リポジトリ flux-image-updates は以下のようなディレクトリ構成になっている.Flux v2 は kustomize を使って構成されるため,設定ファイルとして gotk-components.yamlgotk-sync.yaml も追加されている.

.
└── clusters
    └── my-cluster
        └── flux-system
            ├── gotk-components.yaml # Flux v2 コンポーネント群 (Service, Deployment, CustomResourceDefinition など)
            ├── gotk-sync.yaml # Flux v2 同期コンポーネント群 (GitRepository, Kustomization)
            └── kustomization.yaml # Kustomize 設定 (Kustomization)

アプリケーションを追加する

さっそくアプリケーションを追加する.今回はサンプルとして stefanprodan/podinfo を使う.

github.com

作った GitHub リポジトリ flux-image-updates に Deployment YAML を ./clusters/my-cluster/podinfo-deployment.yaml として追加する.ポイントは Pod のイメージタグで spec.containers.imageGitHub Container Registryghcr.io/stefanprodan/podinfo:5.0.0 を指定している.5.0.0 を覚えておく!

$ git clone https://github.com/${GITHUB_USER}/flux-image-updates
$ cd flux-image-updates

$ cat <<EOF > ./clusters/my-cluster/podinfo-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: podinfo
  namespace: default
spec:
  selector:
    matchLabels:
      app: podinfo
  template:
    metadata:
      labels:
        app: podinfo
    spec:
      containers:
      - name: podinfod
        image: ghcr.io/stefanprodan/podinfo:5.0.0
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 9898
          protocol: TCP
EOF

GitHub リポジトリに Deployment YAML を追加して少し待つ(もしくは flux reconcile kustomization コマンドを使って同期する)と Flux v2 によって Pod がデプロイされる.実際にイメージタグは 5.0.0 になっている.

$ git add -A && \
git commit -m "add podinfo deployment" && \
git push origin main

$ flux reconcile kustomization flux-system --with-source

$ kubectl get deployments.apps podinfo
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
podinfo   1/1     1            1           10s

$ kubectl get deployments.apps podinfo -o yaml | grep 'image:'
      - image: ghcr.io/stefanprodan/podinfo:5.0.0

ImageRepository オブジェクトを追加する

次に flux create image repository コマンドを使って ImageRepository オブジェクトを追加する.

$ flux create image repository podinfo \
--image=ghcr.io/stefanprodan/podinfo \
--interval=1m \
--export > ./clusters/my-cluster/podinfo-registry.yaml

./clusters/my-cluster/podinfo-registry.yaml は以下となる.ImageRepository オブジェクトは指定したイメージリポジトリを監視して「新しいタグ」があるかを確認する.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageRepository
metadata:
  name: podinfo
  namespace: flux-system
spec:
  image: ghcr.io/stefanprodan/podinfo
  interval: 1m0s

ImagePolicy オブジェクトを追加する

さらに flux create image policy コマンドを使って ImagePolicy オブジェクトを追加する.

$ flux create image policy podinfo \
--image-ref=podinfo \
--select-semver=5.0.x \
--export > ./clusters/my-cluster/podinfo-policy.yaml

./clusters/my-cluster/podinfo-policy.yaml は以下となる.ImagePolicy オブジェクトは「どういうポリシーで新しいイメージタグを探すか」を指定する.今回は policy.semver.range: 5.0.x なので「セマンティックバージョニング」「パッチバージョンの最新」を探す.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
  name: podinfo
  namespace: flux-system
spec:
  imageRepositoryRef:
    name: podinfo
  policy:
    semver:
      range: 5.0.x

GitHub Container Registry を確認すると 5.0.x の最新は 5.0.3 だった.

ちなみに「セマンティックバージョニング」 以外に <branch>-<sha1>-<timestamp> などのフォーマットを指定して,任意の「並べ替え可能な条件」もできる.詳しくはドキュメントに載っている.

fluxcd.io

ImageRepository と ImagePolicy を適用する

GitHub リポジトリに ImageRepository YAML と ImagePolicy YAML を追加して少し待つ(もしくは flux reconcile kustomization コマンドを使って同期する)と Flux v2 によってデプロイされる.準備 OK!

$ git add -A && \
git commit -m "add podinfo image scan" && \
git push origin main

$ flux reconcile kustomization flux-system --with-source

$ flux get image repository podinfo
NAME    LAST SCAN               SUSPENDED       READY   MESSAGE                        
podinfo 2022-04-18T00:00:00Z    False           True    successful scan, found 33 tags

$ flux get image policy podinfo
NAME    LATEST IMAGE                            READY   MESSAGE                                                                
podinfo ghcr.io/stefanprodan/podinfo:5.0.3      True    Latest image tag for 'ghcr.io/stefanprodan/podinfo' resolved to: 5.0.3

ImageUpdateAutomation オブジェクトを追加する

Flux v2 の「Automate image updates(自動イメージ更新)機能」を有効化するためには Deployment YAML の spec.containers.image# {"$imagepolicy": "flux-system:podinfo"} のようにコメントを書く必要がある.

spec:
  containers:
  - name: podinfod
    image: ghcr.io/stefanprodan/podinfo:5.0.0 # {"$imagepolicy": "flux-system:podinfo"}

そして flux create image update コマンドを使って ImageUpdateAutomation オブジェクトを追加する.

$ flux create image update flux-system \
--git-repo-ref=flux-system \
--git-repo-path="./clusters/my-cluster" \
--checkout-branch=main \
--push-branch=main \
--author-name=fluxcdbot \
--author-email=fluxcdbot@users.noreply.github.com \
--commit-template="{{range .Updated.Images}}{{println .}}{{end}}" \
--export > ./clusters/my-cluster/flux-system-automation.yaml

./clusters/my-cluster/flux-system-automation.yaml は以下となる.ImageUpdateAutomation オブジェクトは「どういう設定で GitHub リポジトリにコミットをするか」を指定する.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
  name: flux-system
  namespace: flux-system
spec:
  git:
    checkout:
      ref:
        branch: main
    commit:
      author:
        email: fluxcdbot@users.noreply.github.com
        name: fluxcdbot
      messageTemplate: '{{range .Updated.Images}}{{println .}}{{end}}'
    push:
      branch: main
  interval: 1m0s
  sourceRef:
    kind: GitRepository
    name: flux-system
  update:
    path: ./clusters/my-cluster
    strategy: Setters

自動イメージ更新を待つ

GitHub リポジトリに ImageUpdateAutomation YAML を追加して少し待つ(もしくは flux reconcile kustomization コマンドを使って同期する)と Flux v2 によってデプロイされる.少し待っていると 5.0.0 から 5.0.3 に更新された!👏

$ git add -A && \
git commit -m "add image updates automation" && \
git push origin main

$ kubectl get deployments.apps podinfo -o yaml | grep 'image:'
      - image: ghcr.io/stefanprodan/podinfo:5.0.0

(少し待つ...)

$ kubectl get deployments.apps podinfo -o yaml | grep 'image:'
      - image: ghcr.io/stefanprodan/podinfo:5.0.3

GitHub の podinfo-deployment.yaml も Flux v2 によって更新されていた.

spec:
  containers:
  - name: podinfod
    image: ghcr.io/stefanprodan/podinfo:5.0.3 # {"$imagepolicy": "flux-system:podinfo"}

GitHub の差分も載せておく!

マイナーバージョンとパッチバージョンの最新を探す

今度は ImagePolicy オブジェクトを更新して「マイナーバージョンとパッチバージョンの最新」を探す.policy.semver.range: 5.0.x から policy.semver. range: ^5 にした.

---
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
  name: podinfo
  namespace: flux-system
spec:
  imageRepositoryRef:
    name: podinfo
  policy:
    semver:
      range: ^5

GitHub リポジトリに ImageUpdateAutomation YAML を追加して少し待つ(もしくは flux reconcile kustomization コマンドを使って同期する)と Flux v2 によってデプロイされる.少し待っていると 5.0.3 から 5.2.1 に更新された!👏

$ git add -A && \
git commit -m "update image policy" && \
git push origin main

$ kubectl get deployments.apps podinfo -o yaml | grep 'image:'
      - image: ghcr.io/stefanprodan/podinfo:5.0.0

(少し待つ...)

$ kubectl get deployments.apps podinfo -o yaml | grep 'image:'
      - image: ghcr.io/stefanprodan/podinfo:5.2.1

まとめ

Flux v2 でも「Automate image updates(自動イメージ更新)機能」を使って「Image Ops」を実現できることを確認できた.しかし Flux v1 と互換性はなく,多くの CRD (Custom Resource Definitions) を組み合わせた構成になっている点は覚えておくと良さそう.以下のドキュメントに Flux v1 → Flux v2 にマイグレーションする手順が載っている.

fluxcd.io

fluxcd.io

Pod でルートファイルシステムを読み取り専用にする securityContext.readOnlyRootFilesystem

Kubernetes で Pod(正確にはコンテナ単位)に securityContext.readOnlyRootFilesystem: true を設定すると,ルートファイルシステムを読み取り専用にして書き込み操作を抑止できる.アプリケーションのセキュリティ対策として使える.補足をすると Kubernetes 固有の機能ではなく,Docker にも docker run コマンドに --read-only オプションが用意されている.

securityContext:
  readOnlyRootFilesystem: true

検証 : BusyBox

まず securityContext.readOnlyRootFilesystem: true を設定して BusyBox を起動するサンプルマニフェストを作る.

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
  - name: busybox
    image: busybox:1.34
    command: ['sh', '-c', 'sleep 3600']
    securityContext:
      readOnlyRootFilesystem: true

実際に Pod を起動して,書き込み操作(とファイル削除)をすると Read-only file system というエラーになった.

$ kubectl apply -f busybox.yaml 
$ kubectl exec -it busybox -- /bin/sh

/ # touch hello.txt
touch: hello.txt: Read-only file system

/ # rm /bin/sh
rm: remove '/bin/sh'? y
rm: can't remove '/bin/sh': Read-only file system

検証 : nginx

次は securityContext.readOnlyRootFilesystem: true を設定して nginx を起動するサンプルマニフェストを作る.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.21
    securityContext:
      readOnlyRootFilesystem: true

今度は Pod を起動することができなかった.Pod のログを確認すると Read-only file system というエラーで nginx を起動すらできていなかった.実際にアプリケーションに securityContext.readOnlyRootFilesystem: true を設定するのは簡単ではなく,書き込みをする可能性のあるディレクトリを洗い出しておく必要がある.

$ kubectl apply -f nginx.yaml 

$ kubectl logs nginx
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: can not modify /etc/nginx/conf.d/default.conf (read-only file system?)
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2022/04/13 00:00:00 [emerg] 1#1: mkdir() "/var/cache/nginx/client_temp" failed (30: Read-only file system)
nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (30: Read-only file system)

nginx の例だと,Docker Hub の nginx ドキュメントに載っている Running nginx in read-only mode が参考になる.デフォルト構成の nginx では /var/cache/var/run に書き込み操作をすると書いてある.他にもログを確認しながらサンプルマニフェストを修正する.

hub.docker.com

最終的に以下のサンプルマニフェストでうまく Pod を起動できるようになった.今回は emptyDir でボリュームを作って,以下の 3 ディレクトリにマウントした.

  • /etc/nginx/conf.d
  • /var/cache/nginx
  • /var/run
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.21
    securityContext:
      readOnlyRootFilesystem: true
    volumeMounts:
      - name: etc-nginx
        mountPath: /etc/nginx/conf.d
      - name: var-cache
        mountPath: /var/cache/nginx
      - name: var-run
        mountPath: /var/run
  volumes:
    - name: etc-nginx
      emptyDir: {}
    - name: var-cache
      emptyDir: {}
    - name: var-run
      emptyDir: {}

参考 : EKS Best Practices Guides

EKS Best Practices Guides にも securityContext.readOnlyRootFilesystem: true を設定する件が載っている.

aws.github.io

kubelet が他ノードのラベルを操作しないように制限できる NodeRestriction を試した

Kubernetes で有効化できる Admission Plugin である「NodeRestriction」の動作確認をした.簡単にまとめておく!

「NodeRestriction」kubelet に対して Node / Pod の操作範囲を制限できる.具体例を挙げると kubelet によるラベル操作を自ノードに制限し,他ノードを拒否できる.また特定のプレフィックスを付けたラベルは kubelet によって操作できないようにも制限できる.詳しくは以下のドキュメントに載っている.

kubernetes.io

検証環境

今回は kubeadm を使って構築した Kubernetes v1.23.1 クラスタを使う.以下のように controlplanenode01 ノードで構成している.

$ kubectl get nodes
NAME           STATUS   ROLES                  AGE   VERSION
controlplane   Ready    control-plane,master   10d   v1.23.1
node01         Ready    <none>                 10d   v1.23.1

そして kube-apiserver--enable-admission-plugins オプションを確認すると「NodeRestriction」も有効化してある.

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=Node,RBAC
    - --enable-admission-plugins=NodeRestriction

(中略)

さらに今回試す構成図とラベル操作の関係を図にまとめた!

  • my-label=my-value
  • node-restriction.kubernetes.io/my-label=my-value

f:id:kakku22:20220412134309p:plain

検証 1 : ラベル操作

まず,controlplane ノードの kubelet の操作を前提にするために /etc/kubernetes/kubelet.conf を読み込んでおく.

controlplane $ export KUBECONFIG=/etc/kubernetes/kubelet.conf

さっそくラベル my-label=my-valuecontrolplanenode01 ノードに設定する.「NodeRestriction」を有効化しているため controlplane ノードは成功する.しかし node01 ノードは失敗する.

controlplane $ kubectl label node controlplane my-label=my-value
node/controlplane labeled

controlplane $ kubectl label node node01 my-label=my-value
Error from server (Forbidden): nodes "node01" is forbidden: node "controlplane" is not allowed to modify node "node01"

検証 2 : ラベル操作 (node-restriction.kubernetes.io/)

「NodeRestriction」を有効化していると node-restriction.kubernetes.io/ プレフィックスを付けたラベルの更新は「自ノードだとしても」拒否される.ドキュメントには「ワークロードを隔離するために予約されている」と書かれている.以下のように controlplane ノードでも失敗する.

controlplane $ kubectl label node controlplane node-restriction.kubernetes.io/my-label=my-value
Error from server (Forbidden): nodes "controlplane" is forbidden: is not allowed to modify labels: node-restriction.kubernetes.io/my-label

検証 3 : NodeRestriction を無効化する

最後は「NodeRestriction」を無効化する./etc/kubernetes/manifests/kube-apiserver.yamlkube-apiserver--enable-admission-plugins オプションを削除する.すると以下のように controlplanenode01 ノードで全てのラベル操作ができてしまう.

controlplane $ export KUBECONFIG=/etc/kubernetes/kubelet.conf

controlplane $ kubectl label node controlplane my-label=my-value
node/controlplane labeled

controlplane $ kubectl label node node01 my-label=my-value
node/node01 labeled

controlplane $ kubectl label node controlplane node-restriction.kubernetes.io/my-label=my-value
node/controlplane labeled

参考 : kube-bench

参考として「NodeRestriction」CIS Kubernetes Benchmark でも検知できる.kube-apiserver「NodeRestriction」を有効化していないと kube-bench で FAIL になる.

controlplane $ kube-bench

(中略)

[FAIL] 1.2.16 Ensure that the admission control plugin NodeRestriction is set (Automated)

(中略)

1.2.16 Follow the Kubernetes documentation and configure NodeRestriction plug-in on kubelets.
Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and set the --enable-admission-plugins parameter to a
value that includes NodeRestriction.
--enable-admission-plugins=...,NodeRestriction,...

github.com

関連記事

kakakakakku.hatenablog.com

Re:VIEW で textlint-filter-rule-comments を使う

textlint で textlint-filter-rule-comments を使うとコメント記法で「特定のルールを無視する」範囲を設定できる.

github.com

しかし textlint-plugin-review と組み合わせて Re:VIEW で textlint-filter-rule-comments を使う場合は <!-- --> ではなく #@# という Re:VIEW のコメント記法を使う必要がある.ポイントはここまで👌

#@# textlint-disable
#@# textlint-enable

github.com

検証ログ 📄

検証ログを残しておく.まず,今回のサンプルとして textlint-plugin-reviewtextlint-filter-rule-commentstextlint-rule-preset-ja-technical-writing を組み合わせた .textlintrc を作っておく.textlint-filter-rule-commentsfilters に設定してある.

{
  "filters": {
    "comments": true
  },
  "rules": {
    "preset-ja-technical-writing": true
  },
  "plugins": [
    "review"
  ]
}

そして Re:VIEW ドキュメントとして sample.re を作っておく.文章は適当で ja-technical-writing/max-ten でエラーが出るように意図的に を多く使っている.

= サンプル

今日は、とても、良い、天気、です。

さっそく sample.re に textlint を実行すると ja-technical-writing/max-ten でエラーが出る.ここまでは期待した通り!

$ npx textlint ./*.re

  3:14  error  一つの文で""4つ以上使用しています  ja-technical-writing/max-ten

次に今回の文章を例外として ja-technical-writing/max-ten のエラーを無視する(許容する).以下のように textlint-filter-rule-comments のドキュメントに載っているコメント記法をそのまま追加する.

= サンプル

<!-- textlint-disable ja-technical-writing/max-ten -->

今日は、とても、良い、天気、です。

<!-- textlint-enable ja-technical-writing/max-ten -->

すると今度は <!-- の部分に ja-technical-writing/no-exclamation-question-mark のエラーが出てしまう.

$ npx textlint ./*.re

  3:2   error  Disallow to use "!"                    ja-technical-writing/no-exclamation-question-mark
  5:14  error  一つの文で""4つ以上使用しています  ja-technical-writing/max-ten
  7:2   error  Disallow to use "!"                    ja-technical-writing/no-exclamation-question-mark

今回は Markdown ファイルではなく Re:VIEW ファイルを対象にするため,コメント記法は <!-- ではなく #@# を使う必要がある.以下のように sample.re を修正したら textlint でエラーは出なくなった.

= サンプル

#@# textlint-disable ja-technical-writing/max-ten

今日は、とても、良い、天気、です。

#@# textlint-enable ja-technical-writing/max-ten

Re:VIEW のコメント記法に関しては以下のドキュメントに載っている.

github.com

Kubernetes と AppArmor を組み合わせてファイル操作を制限する

AppArmor (Application Armor) とは Linux Security Modules の1つで,プログラムに対して「ファイル操作」「マウント操作」などを制限する.詳しくは以下のドキュメントに載っている.

ubuntu.com

コンテナワークロードのセキュリティ対策として,AppArmor を Kubernetes でも多層防御として使える.今まで試したことがなく,今回は以下の検証環境を使って「Kubernetes と AppArmor」を組み合わせた基本的な制限を試していく!

  • Kubernetes v1.23.0
  • ワーカーノード : Ubuntu 20.04.3 LTS

AppArmor プロファイル

AppArmor では「AppArmor プロファイル」を作って読み込ませる必要がある.今回は Kubernetes ドキュメントに載っている以下のサンプルを使う.構文は少し複雑に見えるけど w = writedeny なので「全てのディレクトリでファイル操作(書き込み)を制限するプロファイル」と言える.

#include <tunables/global>

profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,

  # Deny all file writes.
  deny /** w,
}

kubernetes.io

準備 : AppArmor 適用前

AppArmor を適用する前に通常の動作確認をする.以下のマニフェストを使って Ubuntu Pod を起動する.

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu
spec:
  containers:
    - name: ubuntu
      image: ubuntu:21.10
      command:
        - sleep
        - infinity

Ubuntu Pod に接続をしてファイル操作(書き込み)を試す.期待通りに書き込めた.

  • /hello.txt : OK
  • /tmp/hello.txt : OK
$ kubectl apply -f ubuntu.yaml

$ kubectl exec -it ubuntu -- /bin/sh

# echo 'hello' > hello.txt
# cat hello.txt
hello

# echo 'hello' > /tmp/hello.txt
# cat /tmp/hello.txt
hello

検証 : 全てのディレクトリでファイル操作(書き込み)を制限する

さっそく AppArmor を適用する.まず,ワーカーノードに「AppArmor プロファイル」を読み込ませる.さっき紹介したプロファイルを k8s-apparmor-example-deny-write として保存して,apparmor_parser コマンドを使って読み込ませる.読み込ませたら aa-status コマンドを使って確認できる.

$ sudo apparmor_parser k8s-apparmor-example-deny-write

$ sudo aa-status | egrep 'profiles|k8s-apparmor-example-deny-write'
38 profiles are loaded.
36 profiles are in enforce mode.
   k8s-apparmor-example-deny-write
2 profiles are in complain mode.
5 processes have profiles defined.

次にマニフェストを更新して Ubuntu Pod を起動し直す.Pod に AppArmor プロファイルを適用する場合は annotations を追加する.今回は container.apparmor.security.beta.kubernetes.io/ubuntu: localhost/k8s-apparmor-example-deny-write とした.ubuntu はコンテナ名で localhost/k8s-apparmor-example-deny-write は AppArmor プロファイル名を意味している.

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu
  annotations:
    container.apparmor.security.beta.kubernetes.io/ubuntu: localhost/k8s-apparmor-example-deny-write
spec:
  containers:
    - name: ubuntu
      image: ubuntu:21.10
      command:
        - sleep
        - infinity

もう一度 Ubuntu Pod に接続をしてファイル操作(書き込み)を試す.今度は AppArmor によって制限されているため失敗した.エラー内容としては Permission denied になった.

  • /hello.txt : NG
  • /tmp/hello.txt : NG
$ kubectl apply -f ubuntu.yaml

$ kubectl exec -it ubuntu -- /bin/sh

# echo 'hello' > hello.txt
/bin/sh: 1: cannot create hello.txt: Permission denied

# echo 'hello' > /tmp/hello.txt
/bin/sh: 3: cannot create /tmp/hello.txt: Permission denied

検証 : /tmp でファイル操作(書き込み)を制限する

今度は AppArmor プロファイルを更新して,/tmp に限定してファイル操作(書き込み)を制限する.更新箇所は deny /** w, から deny /tmp/** w, とした.

#include <tunables/global>

profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,

  # Deny all file writes.
  deny /tmp/** w,
}

改めてワーカーノードで「AppArmor プロファイル」を読み込ませる.同じく apparmor_parser コマンドを使うけど,更新するときは apparmor_parser -r コマンドを使う.

$ sudo apparmor_parser -r k8s-apparmor-example-deny-write

もう一度 Ubuntu Pod に接続をしてファイル操作(書き込み)を試す.今度は AppArmor によって制限されているため /tmp のみ失敗した.

  • /hello.txt : OK
  • /tmp/hello.txt : NG
$ kubectl apply -f ubuntu.yaml

$ kubectl exec -it ubuntu -- /bin/sh

# echo 'hello' > hello.txt
# cat hello.txt
hello

# echo 'hello' > /tmp/hello.txt
/bin/sh: 5: cannot create /tmp/hello.txt: Permission denied

参考 : AppArmor プロファイルを生成する

今回は Kubernetes ドキュメントに載っているサンプルを使ったけど,ファイル操作以外も制限できる.AppArmor の apparmor-easyprof コマンド(簡易的な雛形のみ)や aa-genprof コマンド(プロファイリングもする)を使うと「AppArmor プロファイル」を生成できる.

aa-genprof コマンドを使うと自動的に /etc/apparmor.d/ に AppArmor プロファイルが生成されるので,例えば /usr/bin/curl を制限する場合は /etc/apparmor.d/usr.bin.curl というプロファイルになる.今回は w 以外に m = memory map executabler = read が追加されている.

$ sudo apt install -y apparmor-utils
$ sudo apt install -y apparmor-easyprof

$ sudo aa-easyprof /usr/bin/curl
# vim:syntax=apparmor
# AppArmor policy for curl
# ###AUTHOR###
# ###COPYRIGHT###
# ###COMMENT###

#include <tunables/global>

# No template variables specified

"/usr/bin/curl" {
  #include <abstractions/base>

  # No abstractions specified

  # No policy groups specified

  # No read paths specified

  # No write paths specified
}

$ sudo aa-genprof /usr/bin/curl

(中略)

[(S)can system log for AppArmor events] / (F)inish

(中略)

Finished generating profile for /usr/bin/curl.

$ cat /etc/apparmor.d/usr.bin.curl
# Last Modified: Fri Apr  8 04:20:37 2022
#include <tunables/global>

/usr/bin/curl {
  #include <abstractions/base>

  /usr/bin/curl mr,

}

まとめ

コンテナワークロードのセキュリティ対策として,AppArmor と Kubernetes の組み合わせを試した.実際にファイル操作を制限した Pod を起動できた!

関連記事

システムコールを制限するなら seccomp と組み合わせる案もある.詳しくは以下の記事にまとめてある!

kakakakakku.hatenablog.com