IDP のセキュリティ: 統合されたアプローチ
セキュリティを 1 つで 社内開発者プラットフォーム それは追加のレイヤーではありません 遡及的に適用する: そうでなければなりません 設計により統合 のすべてのコンポーネントで プラットフォーム。パラダイム ゼロトラスト (「決して信頼しないでください、常に検証してください」) 安全なプラットフォームのアーキテクチャ基盤: すべてのリクエスト、すべてのアクセス、およびすべての 発信元に関係なく通信が検証されます。
プラットフォーム チームの課題は、セキュリティと開発者エクスペリエンスのバランスを取ることです。ポリシーが多すぎる 制限的な政策は開発を遅らせ、安全でない回避策を奨励する一方、政策が多すぎると 寛容なポリシーは組織をリスクにさらします。解決策は、 セキュリティの自動化: 障害にならずに保護する自動ポリシー適用。
何を学ぶか
- IDP に適用されるゼロトラスト原則
- RBAC および ABAC によるきめ細かなアクセス制御
- OPA と Kyverno によるポリシーの適用
- Vault による自動シークレット管理
- サプライチェーンのセキュリティ: SBOM、イメージ署名、脆弱性スキャン
- コンプライアンスのフレームワーク: GDPR、SOC2、ISO 27001
ゼロトラストアーキテクチャ
モデル ゼロトラスト それは、次のような基本原則に基づいています。 プラットフォームのあらゆるレベルで実装されます。
- 明示的に検証する: 内部ネットワークからのものであっても、すべてのリクエストは認証され、承認されます。
- 最小限の特権アクセス: 各ユーザーとサービスには、その機能を実行するために必要な最小限の権限があります。
- 違反を想定: プラットフォームは侵害が発生する可能性を想定して設計されており、爆発半径を最小限に抑えます。
Kubernetes のコンテキストでは、ゼロ トラストは次のように変換されます。サービス間の必須の mTLS (サービス メッシュ)、 不正なトラフィックをブロックするネットワーク ポリシー、トラフィックを阻止するポッド セキュリティ標準 特権コンテナの実行、および各操作の監査ログ。
# Zero Trust: network policies Kubernetes
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: checkout-service-policy
namespace: checkout
spec:
podSelector:
matchLabels:
app: checkout-service
policyTypes:
- Ingress
- Egress
ingress:
# Solo dal gateway e dal servizio ordini
- from:
- namespaceSelector:
matchLabels:
name: api-gateway
- namespaceSelector:
matchLabels:
name: orders
ports:
- protocol: TCP
port: 8080
egress:
# Solo verso database, cache e servizi necessari
- to:
- namespaceSelector:
matchLabels:
name: databases
ports:
- protocol: TCP
port: 5432
- to:
- namespaceSelector:
matchLabels:
name: cache
ports:
- protocol: TCP
port: 6379
# DNS resolution
- to:
- namespaceSelector:
matchLabels:
name: kube-system
ports:
- protocol: UDP
port: 53
---
# Pod Security Standard: restricted
apiVersion: v1
kind: Namespace
metadata:
name: checkout
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
RBAC および ABAC: きめ細かなアクセス制御
プラットフォームのアクセス制御は次のとおりである必要があります。 粒状 e 自動化された:
- RBAC (ロールベースのアクセス制御): 事前定義された役割 (開発者、技術リーダー、プラットフォーム管理者) に基づいて権限を割り当てます。
- ABAC (属性ベースのアクセス制御): 動的属性 (チーム、環境、時間、場所) に基づく権限
- ジャストインタイムアクセス: 自動承認および有効期限付きの特権リソースへの一時的なアクセス
- ガラス破りの手順: 完全な監査によるハイアクセスな緊急手順
# RBAC: ruoli Kubernetes per il platform team
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: platform-developer
rules:
# Può vedere e gestire i propri deployment
- apiGroups: ["apps"]
resources: ["deployments", "replicasets"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
# Può vedere i pod ma non eliminarli
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
# Può gestire configmap e secrets nel proprio namespace
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
# NON può modificare namespace, RBAC o network policies
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: team-checkout-developer
namespace: checkout
subjects:
- kind: Group
name: team-checkout
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: platform-developer
apiGroup: rbac.authorization.k8s.io
自動ポリシー適用
ポリシーは次のとおりである必要があります 自動的に適用される、善意に頼らないでください 開発者の。 Kubernetes でポリシーを適用するための 2 つの主なツールは次のとおりです。
- OPA/ゲートキーパー: Rego 言語を使用した汎用ポリシー エンジン。強力だが学習曲線が急峻である
- カイベルノ: YAML を使用する Kubernetes ネイティブ ポリシー エンジン。 K8s 固有のポリシーがよりシンプルかつ直感的に
# Kyverno: policy di sicurezza per la piattaforma
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-non-root
spec:
validationFailureAction: Enforce
rules:
- name: run-as-non-root
match:
any:
- resources:
kinds:
- Pod
validate:
message: "I container devono eseguire come non-root"
pattern:
spec:
containers:
- securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-resource-limits
spec:
validationFailureAction: Enforce
rules:
- name: require-limits
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Tutti i container devono avere resource limits"
pattern:
spec:
containers:
- resources:
limits:
memory: "?*"
cpu: "?*"
requests:
memory: "?*"
cpu: "?*"
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-labels
spec:
validationFailureAction: Enforce
rules:
- name: require-team-label
match:
any:
- resources:
kinds:
- Deployment
- StatefulSet
validate:
message: "Tutti i workload devono avere il label 'team'"
pattern:
metadata:
labels:
team: "?*"
app: "?*"
サプライチェーンのセキュリティ
La サプライチェーンのセキュリティ ソフトウェアのライフサイクル全体を保護します。 デプロイメントの依存関係:
- SBOM (ソフトウェア部品表): 各サービスのすべての依存関係の完全なインベントリが自動的に生成されます
- 画像の署名: Cosign/Sigstore を使用してコンテナ イメージに暗号署名を行い、整合性を確保します
- 脆弱性スキャン: CI/CD に統合された Trivy、Snyk、または Grype による自動画像スキャン
- アドミッションコントロール: 署名およびスキャンされたイメージのみをクラスターにデプロイできます。
セキュリティ自動化の原則
セキュリティポリシーで必要な場合 手動アクション 開発者によって、 それは失敗します。セキュリティは自動化する必要があります: CI/CD でのスキャン、CI/CD でのポリシーの適用。 アドミッション コントローラー、自動シークレット ローテーション、自動証明書更新。開発者 セキュリティについて考える必要はありません。プラットフォームがセキュリティを管理します。
コンプライアンスの枠組み
現代の IDP は、次のような規制枠組みへの準拠をサポートする必要があります。
- GDPR: データ暗号化、アクセスログ、データ保持ポリシー、削除の権利
- SOC2: セキュリティ管理、可用性、処理の完全性、機密性、プライバシー
- ISO27001：情報セキュリティマネジメントシステム、リスク評価、継続的改善
- PCI DSS: 支払いデータを管理するプラットフォーム用
プラットフォームはコンプライアンスを遵守する必要があります 連続的かつ自動: 監査証跡 自動、リアルタイムのポリシー適用、自動生成されたコンプライアンス レポート。 これにより、コンプライアンスがストレスの多い年次監査から継続的で苦痛のないプロセスに変わります。
監査ログと監視
のシステム 監査ログ 完全であり、セキュリティとコンプライアンスの基礎:
- 不変ログ: 監査ログは不変であり、コンプライアンスで要求される期間保持される必要があります。
- 集中ログ: すべてのセキュリティ ログは集中システム (SIEM) に流れ込みます。
- リアルタイムのアラート: 重大なセキュリティ イベント (不審なアクセス、権限昇格) に対する即時アラート
- フォレンジック機能: セキュリティインシデントが発生した場合に一連のイベントを再構築する能力
# Audit logging: Kubernetes audit policy
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# Log tutti gli accessi ai secrets
- level: Metadata
resources:
- group: ""
resources: ["secrets"]
# Log tutte le modifiche a RBAC
- level: RequestResponse
resources:
- group: "rbac.authorization.k8s.io"
resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]
# Log tutti i delete
- level: RequestResponse
verbs: ["delete", "deletecollection"]
# Log tutti gli exec nei pod
- level: Request
resources:
- group: ""
resources: ["pods/exec", "pods/attach"]
# Log minimo per le richieste di lettura frequenti
- level: None
resources:
- group: ""
resources: ["events", "nodes/status"]
verbs: ["get", "list", "watch"]
デフォルトのセキュリティ
最も安全な構成は次のとおりです。 デフォルト設定。ゴールデンズ パスには、統合されたセキュリティのベスト プラクティス (非ルート コンテナー、リソース制限、 ネットワーク ポリシー、Vault 経由のシークレット管理。黄金の道を歩む開発者 追加の労力を必要とせずにセキュリティを実現します。