Amazon EKS セキュリティクイズ
このクイズでは、Amazon EKS のセキュリティ機能、ベストプラクティス、設定に関する理解を確認します。
クイズ概要
- EKS の認証と認可
- Network Security
- Container Security
- Data Security
- コンプライアンスと監査
- セキュリティのベストプラクティス
選択問題
1. Amazon EKS で Kubernetes API server へのアクセスを制御する最も効果的な方法は何ですか？
A. IAM users と roles のみを使用する B. Kubernetes RBAC のみを使用する C. 統合された IAM と Kubernetes RBAC を使用する D. API server への network access restrictions のみを使用する
回答を表示
回答: C. 統合された IAM と Kubernetes RBAC を使用する
解説: Amazon EKS で Kubernetes API server へのアクセスを制御する最も効果的な方法は、AWS IAM と Kubernetes RBAC (Role-Based Access Control) の統合を使用することです。このアプローチは、AWS の強力な identity management 機能と Kubernetes のきめ細かな permission control を組み合わせ、包括的な security model を提供します。
IAM と RBAC 統合の主な利点:
多層の認証と認可:
- IAM は API server に接続できる「誰」を制御します（認証）
- RBAC は認証済みユーザーが実行できる「何」を制御します（認可）
AWS Services とのシームレスな統合:
- 既存の AWS IAM policies と roles を活用
- AWS service accounts と workload identities を利用
きめ細かな Permission Control:
- namespaces、resource types、特定の resources に対する詳細な permissions を定義
- 最小権限の原則を実装
実装方法:
aws-auth ConfigMap を設定する:
yamlapiVersion: v1 kind: ConfigMap metadata: name: aws-auth namespace: kube-system data: mapRoles: | - rolearn: arn:aws:iam::123456789012:role/EKSAdminRole username: admin groups: - system:masters - rolearn: arn:aws:iam::123456789012:role/EKSDeveloperRole username: developer groups: - developers mapUsers: | - userarn: arn:aws:iam::123456789012:user/security-auditor username: security-auditor groups: - security-auditorsKubernetes RBAC Roles と Bindings を定義する:
yaml# Developer role definition apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: dev name: developer rules: - apiGroups: ["", "apps", "batch"] resources: ["pods", "deployments", "jobs"] verbs: ["get", "list", "watch", "create", "update", "patch"] --- # Developer role binding apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: developer-binding namespace: dev subjects: - kind: Group name: developers apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: developer apiGroup: rbac.authorization.k8s.ioIAM Policy の例:
json{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:DescribeCluster", "eks:ListClusters" ], "Resource": "*" } ] }
ベストプラクティス:
最小権限の原則を適用する:
- 必要最小限の permissions のみを付与
- permissions を定期的にレビューおよび監査
Role-based Access を実装する:
- 職務に基づいて roles を定義
- 個人ではなく roles に permissions を割り当てる
Temporary Credentials を使用する:
- 長期 credentials の代わりに temporary credentials を使用
- AWS STS (Security Token Service) を活用
定期的な監査と Monitoring:
- CloudTrail で API calls をログ記録
- Kubernetes audit logs を有効化して分析
実践的な実装例:
EKS Cluster Access 用の IAM Role を作成する:
bashaws iam create-role \ --role-name EKSDevRole \ --assume-role-policy-document file://trust-policy.json aws iam attach-role-policy \ --role-name EKSDevRole \ --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicykubeconfig を更新する:
bashaws eks update-kubeconfig \ --name my-cluster \ --role-arn arn:aws:iam::123456789012:role/EKSDevRole \ --region us-west-2RBAC Configuration を適用する:
bashkubectl apply -f rbac-config.yaml
他の選択肢の問題点:
- A. IAM users と roles のみを使用する: IAM は cluster access を制御できますが、Kubernetes resources に対するきめ細かな permissions は提供しません。
- B. Kubernetes RBAC のみを使用する: RBAC は cluster 内の permissions を制御しますが、AWS services との統合がなく、AWS infrastructure-level security を提供しません。
- D. API server への network access restrictions のみを使用する: Network-level control は重要ですが、認証済みユーザーの permissions を制限せず、きめ細かな access control も提供しません。
A. security groups のみを使用する B. Kubernetes Network Policies を使用する C. VPC endpoint policies を使用する D. host-based firewalls を使用する
回答を表示
回答: B. Kubernetes Network Policies を使用する
解説: Amazon EKS で pods 間の network traffic を制限する最も効果的な方法は、Kubernetes Network Policies を使用することです。Network policies は pod レベルで microsegmentation を提供し、pods 間通信をきめ細かく制御できます。
Kubernetes Network Policies の主な利点:
Pod レベルでのきめ細かな制御:
- IP addresses、ports、protocols に基づく filtering
- label-based selectors による動的な policy application
- ingress と egress traffic の両方を制御
宣言的な設定:
- Kubernetes resources として管理
- GitOps と IaC workflows との統合
- version control と監査が可能
CNI Plugins との統合:
- Amazon VPC CNI、Calico、Cilium などとの統合
- network policy enforcement のためのさまざまな選択肢
実装方法:
Default Deny Policy を実装する:
yamlapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny namespace: prod spec: podSelector: {} policyTypes: - Ingress - Egress特定の Applications 間の通信を許可する:
yamlapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-allow namespace: prod spec: podSelector: matchLabels: app: api policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080namespace をまたぐ通信を制御する:
yamlapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-monitoring namespace: prod spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: purpose: monitoring ports: - protocol: TCP port: 9090
EKS での Network Policies の実装:
互換性のある CNI Plugin を選択する:
- Amazon VPC CNI + Calico
- Cilium
- Antrea
Calico Installation Example:
bashkubectl apply -f https://docs.projectcalico.org/manifests/calico-vxlan.yamlCilium Installation Example:
bashhelm repo add cilium https://helm.cilium.io/ helm install cilium cilium/cilium \ --namespace kube-system \ --set nodeinit.enabled=true \ --set kubeProxyReplacement=partial \ --set hostServices.enabled=false \ --set externalIPs.enabled=true \ --set nodePort.enabled=true \ --set hostPort.enabled=true \ --set bpf.masquerade=false \ --set image.pullPolicy=IfNotPresent
ベストプラクティス:
Default Deny Policy から開始する:
- デフォルトですべての traffic をブロック
- 必要な通信のみを明示的に許可
最小権限の原則を適用する:
- 必要最小限の通信のみを許可
- 特定の ports と protocols に制限
Label-based Policies を使用する:
- IP addresses ではなく labels を使用
- 動的な環境で柔軟性を提供
Policies をテストして検証する:
- non-production environments で policies をテスト
- network policy simulator tools を利用
実践的な実装例:
Microservices Architecture 用の Network Policy:
yaml# Allow only frontend to API communication apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-backend namespace: prod spec: podSelector: matchLabels: app: api policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080 egress: - to: - podSelector: matchLabels: app: database ports: - protocol: TCP port: 5432External Service Access を制限する:
yamlapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: limit-external namespace: prod spec: podSelector: matchLabels: app: backend policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.0.0.0/8 - to: - ipBlock: cidr: 0.0.0.0/0 except: - 169.254.0.0/16 - 10.0.0.0/8 ports: - protocol: TCP port: 443
他の選択肢の問題点:
- A. security groups のみを使用する: security groups は instance レベルで動作し、pods 間のきめ細かな traffic control は提供しません。
- C. VPC endpoint policies を使用する: VPC endpoint policies は AWS services へのアクセスを制御しますが、pod-to-pod communication は制御しません。
- D. host-based firewalls を使用する: host-based firewalls は node レベルで動作し、同じ node 上で実行されている pods 間の通信を効果的に制御できません。
A. すべての images に手動の security checks を実施する B. 信頼できる official images のみを使用する C. image scanning、signature verification、admission policies を含む統合 pipeline を実装する D. containers 内で antivirus software を実行する
回答を表示
回答: C. image scanning、signature verification、admission policies を含む統合 pipeline を実装する
解説: Amazon EKS で container image security を強化する最も効果的なアプローチは、image scanning、signature verification、admission policies を含む統合 pipeline を実装することです。この包括的なアプローチにより、build から deployment まで image lifecycle 全体で security を確保できます。
統合 Image Security Pipeline の主な構成要素:
Image Scanning:
- 既知の vulnerabilities (CVEs) を確認
- malware と backdoors を検出
- misconfigurations と security best practice violations を特定
Image Signing and Verification:
- image integrity を確保
- 信頼できる sources を検証
- 改ざんを防止
Admission Policies:
- approved images のみ deployment を許可
- minimum base image requirements を適用
- vulnerability severity thresholds を設定
実装方法:
Amazon ECR Image Scanning を設定する:
bash# Enable scanning when creating repository aws ecr create-repository \ --repository-name my-app \ --image-scanning-configuration scanOnPush=true # Enable scanning for existing repository aws ecr put-image-scanning-configuration \ --repository-name my-app \ --image-scanning-configuration scanOnPush=trueAWS Signer を使用して Images に署名する:
bash# Create signing profile aws signer put-signing-profile \ --profile-name MyAppSigningProfile \ --platform-id Aws::ECR::Image # Sign image aws signer start-signing-job \ --source "s3={bucketName=my-bucket,key=my-image.tar}" \ --destination "s3={bucketName=my-bucket,prefix=signed/}" \ --profile-name MyAppSigningProfileKyverno を使用して Image Policies を適用する:
yamlapiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: require-signed-images spec: validationFailureAction: enforce rules: - name: verify-image-signature match: resources: kinds: - Pod verifyImages: - image: "*.dkr.ecr.*.amazonaws.com/*" key: "https://my-keystore.com/keys/my-key.pub"OPA Gatekeeper を使用して Image Policies を適用する:
yamlapiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sTrustedImages metadata: name: trusted-repos spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] parameters: repos: - "123456789012.dkr.ecr.us-west-2.amazonaws.com/*" - "docker.io/library/*"
統合 Pipeline の構築:
CI/CD Pipeline Integration:
yaml# AWS CodePipeline example version: 0.2 phases: pre_build: commands: - echo Logging in to Amazon ECR... - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $ECR_REPOSITORY_URI build: commands: - echo Building the Docker image... - docker build -t $ECR_REPOSITORY_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION . post_build: commands: - echo Running security scan... - trivy image --exit-code 1 --severity HIGH,CRITICAL $ECR_REPOSITORY_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION - echo Signing the image... - aws signer start-signing-job --profile-name MyAppSigningProfile --source-image $ECR_REPOSITORY_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION - echo Pushing the Docker image... - docker push $ECR_REPOSITORY_URI:$CODEBUILD_RESOLVED_SOURCE_VERSIONImage Admission Controller をデプロイする:
bash# Install Kyverno kubectl create -f https://github.com/kyverno/kyverno/releases/download/v1.8.0/install.yaml # Apply policy kubectl apply -f image-policy.yaml
ベストプラクティス:
Minimal Base Images を使用する:
- attack surface を最小化
- 必要な components のみを含める
- distroless または lightweight images を使用
Defense in Depth を実装する:
- build-time scanning
- pre-deployment validation
- runtime monitoring
Images を定期的に更新する:
- 最新の security patches を適用
- base images を定期的に更新
- vulnerabilities を継続的に監視
Immutable Images を使用する:
- deployment 後に images を変更しない
- 変更が必要な場合は新しい images を build および deploy
- version management と rollback をサポート
実践的な実装例:
Amazon ECR、AWS CodePipeline、Kyverno の統合:
yaml# buildspec.yml version: 0.2 phases: pre_build: commands: - echo Logging in to Amazon ECR... - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $ECR_REPOSITORY_URI - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7) - IMAGE_TAG=${COMMIT_HASH:=latest} build: commands: - echo Building the Docker image... - docker build -t $ECR_REPOSITORY_URI:$IMAGE_TAG . post_build: commands: - echo Running Trivy security scan... - trivy image --exit-code 1 --severity HIGH,CRITICAL $ECR_REPOSITORY_URI:$IMAGE_TAG - echo Pushing the Docker image... - docker push $ECR_REPOSITORY_URI:$IMAGE_TAG - echo Creating image definition file... - aws ecr describe-images --repository-name $(echo $ECR_REPOSITORY_URI | cut -d'/' -f2) --image-ids imageTag=$IMAGE_TAG --query 'imageDetails[].imageTags[0]' --output text artifacts: files: - imagedefinitions.jsonKyverno Image Policy:
yamlapiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: restrict-image-registries spec: validationFailureAction: enforce background: true rules: - name: allowed-registries match: resources: kinds: - Pod validate: message: "Only images from approved registries are allowed" pattern: spec: containers: - image: "{{ regex_match('123456789012.dkr.ecr.*.amazonaws.com/*|docker.io/library/*', '@@') }}"
他の選択肢の問題点:
- A. すべての images に手動の security checks を実施する: 手動チェックは scalable ではなく、一貫性に欠け、continuous deployment environments では実用的ではありません。
- B. 信頼できる official images のみを使用する: official images であっても vulnerabilities が存在する可能性があり、custom images が必要になることもよくあります。
- D. containers 内で antivirus software を実行する: containers 内で antivirus を実行すると多くの resources を使用し、container design principles に反し、image build stage の security issues に対処できません。
A. すべての pods で privileged mode を無効にする B. Pod Security Standards (PSS) と Pod Security Policies (PSP) を実装する C. すべての pods を non-root users として実行する D. すべての pods で read-only file systems を使用する
回答を表示
回答: B. Pod Security Standards (PSS) と Pod Security Policies (PSP) を実装する
解説: Amazon EKS で pod security を強化する最も効果的な方法は、Pod Security Standards (PSS) と Pod Security Policies (PSP)、またはそれらの replacement mechanisms を実装することです。これらの仕組みは pods の security context を制御し、cluster 全体に一貫した security standards を適用します。
注記: Kubernetes 1.25 以降、PSP (Pod Security Policy) は deprecated であり、代わりに PSS (Pod Security Standards) と PSA (Pod Security Admission) が推奨されています。EKS では、Kyverno や OPA Gatekeeper などの policy engines を使用して同様の機能を実装できます。
Pod Security Standards and Policies の主な利点:
一貫した Security Standards を適用する:
- cluster 全体に一貫した security controls を適用
- privilege escalation を防止
- container escape risk を低減
さまざまな Security Levels をサポート:
- Privileged: 制限なし
- Baseline: 基本的な制限を適用
- Restricted: 厳格な security controls を適用
きめ細かな Security Controls:
- privilege escalation を制限
- host namespace access を制限
- volume types を制限
- user and group IDs を制限
実装方法:
Pod Security Standards (PSS) を適用する:
yaml# Apply PSS labels to namespace apiVersion: v1 kind: Namespace metadata: name: secure-ns labels: pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/audit: restricted pod-security.kubernetes.io/warn: restrictedKyverno を使用して Pod Security Policy を実装する:
yamlapiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: restrict-privileged spec: validationFailureAction: enforce rules: - name: no-privileged-pods match: resources: kinds: - Pod validate: message: "Privileged mode is not allowed" pattern: spec: containers: - name: "*" securityContext: privileged: falseOPA Gatekeeper を使用して Pod Security Policy を実装する:
yamlapiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sPSPPrivilegedContainer metadata: name: no-privileged-containers spec: match: kinds: - apiGroups: [""] kinds: ["Pod"]
主な Pod Security Controls:
Privileged Mode を制限する:
yamlsecurityContext: privileged: falseNon-root User として実行する:
yamlsecurityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000Capabilities を制限する:
yamlsecurityContext: capabilities: drop: - ALL add: - NET_BIND_SERVICERead-only Root Filesystem:
yamlsecurityContext: readOnlyRootFilesystem: trueseccomp Profile を適用する:
yamlsecurityContext: seccompProfile: type: RuntimeDefault
ベストプラクティス:
最小権限の原則を適用する:
- 必要最小限の permissions のみを付与
- privileged mode の使用を制限
- 必要な capabilities のみを許可
Defense in Depth を実装する:
- Namespace-level policies
- Cluster-level policies
- Runtime security monitoring
Security Context を明示的に定義する:
- defaults に依存しない
- すべての containers に security context を指定
- security configurations を定期的にレビュー
Policy Exceptions を管理する:
- exceptions が必要な場合の明確な processes を定義
- exceptions を定期的にレビューおよび監査
- exceptions を最小化
実践的な実装例:
Security-enhanced Pod Definition:
yamlapiVersion: v1 kind: Pod metadata: name: secure-pod spec: securityContext: fsGroup: 2000 runAsNonRoot: true runAsUser: 1000 seccompProfile: type: RuntimeDefault containers: - name: app image: my-secure-app:1.0 securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 1000 seccompProfile: type: RuntimeDefaultKyverno Policy Collection:
yamlapiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: pod-security spec: validationFailureAction: enforce rules: - name: no-privileged match: resources: kinds: - Pod validate: message: "Privileged containers are not allowed" pattern: spec: containers: - name: "*" securityContext: privileged: false - name: no-privilege-escalation match: resources: kinds: - Pod validate: message: "Privilege escalation is not allowed" pattern: spec: containers: - name: "*" securityContext: allowPrivilegeEscalation: false - name: require-non-root match: resources: kinds: - Pod validate: message: "Running as root is not allowed" pattern: spec: containers: - name: "*" securityContext: runAsNonRoot: true
他の選択肢の問題点:
- A. すべての pods で privileged mode を無効にする: privileged mode の無効化は重要ですが、pod security の一側面にすぎず、包括的な security strategy は提供しません。
- C. すべての pods を non-root users として実行する: non-root として実行することは良い practice ですが、他の重要な security controls（例: capabilities、volume mounts、host namespace access）には対応しません。
- D. すべての pods で read-only file systems を使用する: Read-only file systems は有用な security control ですが、すべての applications に適しているわけではなく、他の重要な security aspects には対応しません。
A. 手動の security reviews を実施する B. AWS Config rules のみを使用する C. AWS GuardDuty のみを使用する D. 統合された AWS Security Hub、GuardDuty、CloudTrail、Kubernetes audit logs を使用する
回答を表示
回答: D. 統合された AWS Security Hub、GuardDuty、CloudTrail、Kubernetes audit logs を使用する
解説: Amazon EKS で security compliance を監視および監査する最も効果的なアプローチは、AWS Security Hub、GuardDuty、CloudTrail、Kubernetes audit logs を統合することです。この統合アプローチにより、infrastructure、cluster、application レベルで包括的な security visibility を提供できます。
統合 Security Monitoring and Auditing の主な利点:
多層の Security Visibility:
- AWS infrastructure-level monitoring
- Kubernetes cluster-level auditing
- Container and application-level security events
自動化された Compliance Checks:
- industry standards と best practices への compliance を検証
- configuration drift を検出
- continuous compliance monitoring
一元化された Security Management:
- 単一の dashboard から security status を確認
- 統合された alerting と response
- 包括的な security reports
実装方法:
AWS Security Hub を有効化する:
bash# Enable Security Hub aws securityhub enable-security-hub \ --enable-default-standards \ --tags Environment=ProductionAmazon GuardDuty EKS Protection を有効化する:
bash# Enable GuardDuty aws guardduty create-detector \ --enable \ --finding-publishing-frequency FIFTEEN_MINUTES # Enable EKS Protection aws guardduty update-detector \ --detector-id $(aws guardduty list-detectors --query 'DetectorIds[0]' --output text) \ --features '[{"Name": "EKS_RUNTIME_MONITORING", "Status": "ENABLED"}]'CloudTrail Logging を設定する:
bash# Create CloudTrail trail aws cloudtrail create-trail \ --name eks-audit-trail \ --s3-bucket-name my-eks-audit-logs \ --is-multi-region-trail \ --enable-log-file-validation # Enable trail logging aws cloudtrail start-logging \ --name eks-audit-trailEKS Audit Logs を有効化する:
bash# Enable audit logs when creating cluster aws eks create-cluster \ --name my-cluster \ --role-arn arn:aws:iam::123456789012:role/EKSClusterRole \ --resources-vpc-config subnetIds=subnet-12345,subnet-67890,securityGroupIds=sg-12345 \ --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' # Enable audit logs for existing cluster aws eks update-cluster-config \ --name my-cluster \ --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'
主な Monitoring and Auditing Components:
AWS Security Hub:
- EKS best practice standards を適用
- CIS Kubernetes benchmark checks
- security findings を一元化
Amazon GuardDuty:
- EKS runtime monitoring
- Container threat detection
- Anomaly detection
AWS CloudTrail:
- EKS control plane API calls をログ記録
- management events を追跡
- user activity を監査
Kubernetes Audit Logs:
- in-cluster activity をログ記録
- API server requests を追跡
- permission changes を監視
Amazon CloudWatch:
- logs を一元化
- metrics を監視
- alerts を設定
ベストプラクティス:
包括的な Logging Strategy を実装する:
- すべての関連 log sources を有効化
- 適切な log retention policies を設定
- log integrity を確保
自動化された Compliance Checks を設定する:
- 定期的な compliance scans をスケジュール
- critical violations の alerts を設定
- compliance reports を自動化
Security Events への Response Plans を確立する:
- 明確な escalation paths を定義
- automated responses を実装
- response plans を定期的にテスト
最小権限の原則を適用する:
- audit logs へのアクセスを制限
- security tools に role-based access control を適用
- permissions を定期的にレビュー
実践的な実装例:
AWS Security Hub and GuardDuty Integration:
bash# Send Security Hub findings to SNS topic aws events put-rule \ --name SecurityHubFindings \ --event-pattern '{"source":["aws.securityhub"],"detail-type":["Security Hub Findings - Imported"]}' aws events put-targets \ --rule SecurityHubFindings \ --targets 'Id"="1","Arn"="arn:aws:sns:us-west-2:123456789012:security-alerts"'Audit Log Analysis with CloudWatch Logs Insights:
fields @timestamp, @message | filter @logStream like /kube-apiserver-audit/ | filter @message like "system:serviceaccount" | filter @message like "create" or @message like "update" or @message like "delete" | sort @timestamp desc | limit 100AWS Config Rules で EKS Configuration を監視する:
bash# Create Config rule to check if EKS cluster endpoint is public aws configservice put-config-rule \ --config-rule file://eks-endpoint-rule.jsonTerraform で Security Monitoring Infrastructure を設定する:
hcl# Enable GuardDuty resource "aws_guardduty_detector" "main" { enable = true finding_publishing_frequency = "FIFTEEN_MINUTES" } # Enable EKS Protection resource "aws_guardduty_detector_feature" "eks_runtime" { detector_id = aws_guardduty_detector.main.id name = "EKS_RUNTIME_MONITORING" status = "ENABLED" } # Enable Security Hub resource "aws_securityhub_account" "main" {} # Enable EKS standards resource "aws_securityhub_standards_subscription" "cis_eks" { depends_on = [aws_securityhub_account.main] standards_arn = "arn:aws:securityhub:${data.aws_region.current.name}::standards/aws-foundational-security-best-practices/v/1.0.0" }
他の選択肢の問題点:
- A. 手動の security reviews を実施する: 手動レビューは scalable ではなく、real-time threat detection を提供せず、human error が起こりやすいです。
- B. AWS Config rules のみを使用する: AWS Config は configuration compliance の監視に有用ですが、runtime threat detection や包括的な logging は提供しません。
- C. AWS GuardDuty のみを使用する: GuardDuty は threat detection に重点を置きますが、configuration compliance checks や包括的な audit logging は提供しません。
A. default settings の Kubernetes Secrets を使用する B. secrets を environment variables として渡す C. AWS Secrets Manager または AWS Parameter Store と統合する D. container images に secrets を hardcode する
回答を表示
回答: C. AWS Secrets Manager または AWS Parameter Store と統合する
解説: Amazon EKS で secrets management を行う最も安全なアプローチは、AWS Secrets Manager や AWS Parameter Store のような専用の secret management services と統合することです。これらの services は、encryption、access control、automatic rotation、auditing などの高度な security features を提供します。
AWS Secret Management Service Integration の主な利点:
強力な Encryption:
- AWS KMS を使用した encryption at rest
- encryption in transit
- きめ細かな encryption key management
きめ細かな Access Control:
- IAM policies による access control
- 最小権限の原則を適用
- temporary credentials のサポート
Automatic Secret Rotation:
- 定期的な secret rotation を自動化
- application を中断せずに rotate
- rotation schedules と policies を管理
包括的な Auditing and Logging:
- secret access を監査
- CloudTrail との統合
- compliance requirements を満たす
実装方法:
AWS Secrets Manager との統合:
a. ASCP (AWS Secrets and Configuration Provider) をインストールする:
bashhelm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts helm install -n kube-system csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/deployment/aws-provider-installer.yamlb. SecretProviderClass を作成する:
yamlapiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: aws-secrets spec: provider: aws parameters: objects: | - objectName: "prod/myapp/db-creds" objectType: "secretsmanager" objectAlias: "db-creds.json" secretObjects: - secretName: db-credentials type: Opaque data: - objectName: db-creds.json key: username property: username - objectName: db-creds.json key: password property: passwordc. Pod に Secrets をマウントする:
yamlapiVersion: v1 kind: Pod metadata: name: app spec: containers: - name: app image: myapp:1.0 volumeMounts: - name: secrets-store mountPath: "/mnt/secrets" readOnly: true env: - name: DB_USERNAME valueFrom: secretKeyRef: name: db-credentials key: username - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-credentials key: password volumes: - name: secrets-store csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: aws-secretsAWS Parameter Store との統合:
a. External Secrets Operator をインストールする:
bashhelm repo add external-secrets https://charts.external-secrets.io helm install external-secrets external-secrets/external-secrets \ -n external-secrets \ --create-namespaceb. SecretStore を作成する:
yamlapiVersion: external-secrets.io/v1beta1 kind: SecretStore metadata: name: aws-parameter-store spec: provider: aws: service: ParameterStore region: us-west-2 auth: jwt: serviceAccountRef: name: external-secrets-sac. ExternalSecret を作成する:
yamlapiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: db-credentials spec: refreshInterval: 1h secretStoreRef: name: aws-parameter-store kind: SecretStore target: name: db-credentials data: - secretKey: username remoteRef: key: /prod/myapp/db/username - secretKey: password remoteRef: key: /prod/myapp/db/password
Secret Management のベストプラクティス:
最小権限の原則を適用する:
- 必要な secrets へのアクセスのみを付与
- service account ごとに IAM roles を使用
- 定期的な permission reviews
Automatic Secret Rotation を実装する:
bash# Configure AWS Secrets Manager automatic rotation aws secretsmanager rotate-secret \ --secret-id prod/myapp/db-creds \ --rotation-lambda-arn arn:aws:lambda:us-west-2:123456789012:function:RotateDBCreds \ --rotation-rules '{"AutomaticallyAfterDays": 30}'Secret Encryption を強化する:
bash# Encrypt secrets with customer-managed KMS key aws secretsmanager create-secret \ --name prod/myapp/api-key \ --secret-string '{"api-key": "abcdef12345"}' \ --kms-key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890abSecret Access を監査する:
bash# Filter CloudTrail events aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue
実践的な実装例:
AWS Secrets Manager と IRSA (IAM Roles for Service Accounts) の統合:
yaml# Create service account apiVersion: v1 kind: ServiceAccount metadata: name: app-sa namespace: default annotations: eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/app-role --- # Deployment configuration apiVersion: apps/v1 kind: Deployment metadata: name: app spec: selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: serviceAccountName: app-sa containers: - name: app image: myapp:1.0 volumeMounts: - name: secrets-store mountPath: "/mnt/secrets" readOnly: true volumes: - name: secrets-store csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: aws-secretsTerraform で Secret Management Infrastructure を設定する:
hcl# Create AWS Secrets Manager secret resource "aws_secretsmanager_secret" "db_credentials" { name = "prod/myapp/db-creds" recovery_window_in_days = 7 kms_key_id = aws_kms_key.secrets_key.arn } resource "aws_secretsmanager_secret_version" "db_credentials" { secret_id = aws_secretsmanager_secret.db_credentials.id secret_string = jsonencode({ username = "dbuser", password = random_password.db_password.result }) } # IAM role and policy resource "aws_iam_role" "app_role" { name = "app-role" assume_role_policy = jsonencode({ Version = "2012-10-17", Statement = [{ Effect = "Allow", Principal = { Federated = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:oidc-provider/${module.eks.oidc_provider}" }, Action = "sts:AssumeRoleWithWebIdentity", Condition = { StringEquals = { "${module.eks.oidc_provider}:sub" = "system:serviceaccount:default:app-sa" } } }] }) } resource "aws_iam_policy" "secrets_access" { name = "secrets-access" policy = jsonencode({ Version = "2012-10-17", Statement = [{ Effect = "Allow", Action = [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], Resource = aws_secretsmanager_secret.db_credentials.arn }] }) } resource "aws_iam_role_policy_attachment" "secrets_access" { role = aws_iam_role.app_role.name policy_arn = aws_iam_policy.secrets_access.arn }
他の選択肢の問題点:
- A. default settings の Kubernetes Secrets を使用する: default の Kubernetes Secrets は base64-encoded（encrypted ではない）だけであり、automatic rotation やきめ細かな access control features がありません。
- B. secrets を environment variables として渡す: Environment variables は logs に露出したり process information からアクセスされたりする可能性があり、automatic rotation や auditing features もありません。
- D. container images に secrets を hardcode する: images に secrets を hardcode すると深刻な security risks が生じ、secrets を rotate する必要がある場合に images の rebuild と redeploy が必要になります。