-
- 公開イメージ400万の半数に重大な脆弱性が見つかる
- 無料セキュリティチェック
-
Centos7移行に伴うコンテナベースOSの選定
-
- 公式イメージなどの信頼度の高そうなイメージかつArm版が存在する場合は管理の手間が減る
- マルチステージビルドでのコンテナベースOSと異なる場合、動作しない場合あり(helm,helmfileで確認)
- 親イメージ見つけて一つのDockerfileにまとめる
- 秘匿情報
- 公式イメージなどの信頼度の高そうなイメージかつArm版が存在する場合は管理の手間が減る
-
- 参考イメージ:bitnami | github issue
- 1年間arm更新なし
- 参考イメージ:bitnami | github issue
-
-
公式Helm Dockerfile
- ベースイメージがalpineだったため、使用できず
-
chatworkARM版あり
- Officialでない
-
公式Helm Dockerfile
-
helm
- Verified Publisheであるibmcom/helm等 -> ARM版なし
- [alpine/helm, chatwork/helm] ARM版あり
- officiadでない
-
postgresql
- image => yum install
-
- arm版あり、SPONSORED OSS
- amazon-linux-extras => amazonlinux2022からなくなるため利用せず
-
k8s
- alpineのk8s関連dockerfile
- chatworksのk8s関連dockerfile
- ClusterRoleBindingとService Account
- Podとして実行する場合、kubectlは使えるが権限がない
- Service Accountの作成
- S3への接続確認(pg_dump)のためannotationsにrole付与
-
Centos7移行に伴うコンテナベースOSの選定
-
- CentOS:2024年6月末でサポート終了
-
-
候補
- Alma◎, Rocky
- AmazonLinux2
- HULFT対応
-
2024年6月末でサポート終了
-
AmazonLinux2->amazon linux2022
- rpmベースの汎用Linuxディストリビューションで、Amazon Linux 2 の後継
- 2022/11/3 時点でRC版のみ
- 5年間の長期サポート
-
AmazonLinux2->amazon linux2022
- Amazon Linux 2 は RedHat 7 がベース
-
メリット
- AWS のサービスを運用するために必要なパッケージや設定が事前に入る
- 多くの AWS サービスと容易に統合
- Ubuntu
- alpine
- 軽量であるが、マルチステージビルドした場合errorや不具合(マルチステージビルドの場合)
- ansibleでは利用可能か?
- IAMのポリシーなどコンテナに与える権限を最小化したい。
- オペレーションのコンテナを用途ごとに作成すると構成管理の手間が増えてしまう
- サーバ権限関係サイト
-
AWS API(Terraform, Ansibleなど), K8S API(kubectl, helm, helmfileなど), OS(Ansible)
-
許可policy
- role(IAM)とはAWSのAPIに対しての権限を制御するためのサービス
-
pod
- EKS運用のGitLab RunnerジョブにAWSのIAMロールを適用する方法
- NodeのIAMロールを利用する場合、そのNode上で動くKubernetesクラスターの全Podに同じIAMポリシーが適用⇒最小権限の法則に反する
-
各CLI権限
- k8s-cli
- RDS(psqlコマンド)
- エンドポイント経由
- Terraform/Ansible
- IRSA : IAM Roles for Service Accounts
-
ansible実行時のawsメタデータ取得
- AWS 管理ポリシー: ReadOnlyAccess ansible実行時のfactで必要なため
-
許可policy
- role(IAM)とはAWSのAPIに対しての権限を制御するためのサービス
-
- 基礎用語
-
Kubernetes のストレージについて調べる
-
- データの永続化, Pod内でのコンテナ間のデータ共有
- emptyDir :
- []
- persistentVolumeClaim PVC
-