AWS Load Balancer Controller v2.3.0 から導入された optimized security group rules という機能について記載します。
直訳すると、最適化されたセキュリティグループルール です。
なにコレ?という感じですが、
ALBに独自で作成したセキュリティグループを割り当てた際は、これまではクラスタのセキュリティグループにALBからのインバウンドトラフィックの許可を別で管理する必要がありました。
しかし、この機能の導入によりコントローラが自動で管理してくれるようになります。
TL;DR
結論を先に書くと以下のとおりです。
前提
- v2.3.0+
- Kubernetes 1.16+ (v2.3.0時点)
- cert-manager v1.5.3+ (v2.3.0時点)
- 最新バージョンは下記参照
設定方法
ingressのannotationsで下記のように設定します。
metadata:
annotations:
alb.ingress.kubernetes.io/security-groups: sg-xxxx, nameOfSg1, nameOfSg2
alb.ingress.kubernetes.io/manage-backend-security-group-rules: "true"
これまで
デフォルトではALBに付与するSGはコントローラが自動生成し、クラスタSGにALBからのインバウンドトラフィックを許可する設定も自動で追加されます。
しかし、独自のSGをALBに割り当てたいと考えたとき、v2.3.0 より前のバージョンでは、alb.ingress.kubernetes.io/security-groups
のannotationsで独自のSGを設定できますが、クラスタSGにALBからのインバウンドトラフィック許可は別で管理する必要がありました。
v2.3.0 で何が変わったか
optimized security group rules (最適化されたセキュリティグループルール)が導入されたことにより、
独自のSGをALBに割り当てても、クラスタSGにALBからのインバウンドトラフィック許可もコントローラが自動で管理してくれるようになりました。
リリースノート:https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/tag/v2.3.0
機能Issue:https://github.com/kubernetes-sigs/aws-load-balancer-controller/issues/2118
具体的な変更点
ALBに付与されるSGは2種類になりました。
- フロントエンドSG
- インバウンドルールを管理するもの
- ALBごとに付与されるSG
- デフォルトでは自動生成
- 独自SGはingressのannotationsで設定することができる
- バックエンドSG (New!)
- アウトバウンドルールを管理するもの
- クラスタ内のALB共通のSG
- デフォルトでは自動生成
独自のSGをALBに割り当てても、クラスタSGにALBからのインバウンドトラフィック許可もコントローラが自動で管理してくれるようになりました。
と記載しましたが厳密には、フロントエンドSGである独自のSGを設定しても、コントローラがバックエンドSGをクラスタSGのインバウンドルールに自動で適用してくれているので、別管理しなくてもよくなったということです。
この機能の本来の目的は、ALBが増えるごとにクラスタのSGルールが増え、クォーター制限にかかることを回避するために導入されました。
これまでは、クラスタSGに付与するALBからのインバウンドトラフィックルールは、ALBごとのSG(のちのフロントエンドSG)をALBの数のだけ設定されていました。
これが共通のSGであるバックエンドSGを付与するようにしたので、ALBが増えてもSGルールは1つだけでよくなり、クォーター制限を気にすることはなくなったということです。
設定方法
ではどのように設定するか記載していきます。
前提
v.2.3.0からの機能になるので、v2.3.0 以上である必要があります。
現時点(2022/08/03)ではv2.4.2が最新になりますので、それまでの条件を記載しています。
最新バージョンは下記リリースノートをご参照ください。
ref. https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases
- v2.3.0
- Kubernetes 1.16+
- cert-manager v1.5.3+
- v2.4.2
- Kubernetes 1.19+
設定
ingressのannotationsで下記のように設定します。
metadata:
annotations:
alb.ingress.kubernetes.io/security-groups: sg-xxxx, nameOfSg1, nameOfSg2
alb.ingress.kubernetes.io/manage-backend-security-group-rules: "true"
alb.ingress.kubernetes.io/security-groups
にSGのIDもしくはSG名を記載します。
alb.ingress.kubernetes.io/manage-backend-security-group-rules
はバックエンドSGをコントローラが管理するかどうかの設定なのでtrue
にします。
詳細はAWS Load Balancer Controllerのドキュメントをご参照ください。
ref. https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/ingress/annotations/#security-groups
v2.3.0 以上に Upgrade する際の注意点
リリースノートに記載がありますが、v2.3.0 以上に Upgrade する際は以下の点に注意する必要があります。
This release introduces optimized security group rules for ALB. The controller uses a shared security group across multiple ALBs in the cluster to allow access to your application pods. As a result, your existing ALBs get updated on controller upgrade. There is a possible time window during reconfiguration where your client traffic might get impacted. We recommend upgrading the controller during a maintenance window.
- コントローラのアップグレード時に既存のALBが更新されます。再構成中に、クライアントトラフィックが影響を受ける可能性のある時間枠があります。メンテナンス期間中にコントローラをアップグレードすることをお勧めします。
-> 上記で記載してきた変更点を踏まえると、ALBのバックエンドSGの設定追加や、クラスタSGのインバウンドルールに変更が加わるため、クライアントトラフィックが影響を受ける可能性があると記載しているのだと思います。
まとめ
AWS Load Balancer Controller v2.3.0 から導入された optimized security group rules 機能について記載しました。
ALBに独自のセキュリティグループを割り当てた際は、これまではクラスタのセキュリティグループにALBからのインバウンドトラフィックの許可を別で管理する必要がありました。
しかし、この機能の導入によりコントローラが自動で管理してくれるようになりました。
optimized security group rules?となっていた人の助けになれば幸いです。