Les versions de Tanzu Kubernetes Grid (TKG) sont validées en permanence par rapport au guide DISA (Defense Information Systems Agency) Guides de mise en œuvre technique de la sécurité (STIG) Kubernetes et Guide de sécurisation renforcée Kubernetes NSA/CISA.
Les clusters de charge de travail TKG hérités déployés par des clusters de gestion autonomes peuvent être renforcés à l'aide de la superposition ytt. Pour plus d'informations sur la personnalisation des clusters TKG à l'aide de ytt, reportez-vous à Configuration de cluster hérité avec ytt.
Pour assurer la sécurisation renforcée des clusters TKG, VMware fournit une superposition ytt de sécurisation renforcée STIG.
L'extrait de code suivant est une superposition ytt pour définir tls-min-version (STIG : V-242378) sur le api-server.
#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@overlay/match missing_ok=True,by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
kubeadmConfigSpec:
clusterConfiguration:
apiServer:
extraArgs:
#@overlay/match missing_ok=True
tls-min-version: VersionTLS12
Pour assurer la sécurisation renforcée des clusters TKG pour NSA/CISA, VMware fournit les spécifications d'objet Antrea suivantes :
Sécurisation renforcée NSA/CISA : ClusterNetworkPolicies Antrea :
La spécification ClusterNetworkPolicies Antrea suivante pour le contrôle des stratégies réseau définit une stratégie par défaut pour que l'ensemble des espaces refusent tout le trafic d'entrée et de sortie et s'assurent que tous les espaces non sélectionnés sont isolés.
apiVersion: security.antrea.tanzu.vmware.com/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: default-deny
spec:
priority: 150
tier: baseline
appliedTo:
- namespaceSelector: {}
ingress:
- action: Drop # For all Pods in every namespace, drop and log all ingress traffic from anywhere
name: drop-all-ingress
enableLogging: true
egress:
- action: Drop # For all Pods in every namesapces, drop and log all egress traffic towards anywhere
name: drop-all-egress
enableLogging: true
Sécurisation renforcée NSA/CISA : Stratégie réseau Antrea :
La stratégie réseau Antrea suivante autorise la sortie de tanzu-capabilities-manager vers les ports 443 et 6443 de kube-apiserver.
apiVersion: security.antrea.tanzu.vmware.com/v1alpha1
kind: NetworkPolicy
metadata:
name: tanzu-cm-apiserver
namespace: tkg-system
spec:
priority: 5
tier: securityops
appliedTo:
- podSelector:
matchLabels:
app: tanzu-capabilities-manager
egress:
- action: Allow
to:
- podSelector:
matchLabels:
component: kube-apiserver
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
ports:
- port: 443
protocol: TCP
- port: 6443
protocol: TCP
name: AllowToKubeAPI
Sécurisation renforcée NSA/CISA : Modèle et contraintes OPA :
L'exemple suivant utilise le contrôle d'accès OPA pour limiter les référentiels d'images autorisés.
Modèle OPA :
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8sallowedrepos
annotations:
description: Requires container images to begin with a repo string from a specified
list.
spec:
crd:
spec:
names:
kind: K8sAllowedRepos
validation:
# Schema for the `parameters` field
openAPIV3Schema:
type: object
properties:
repos:
type: array
items:
type: string
targets:
- target: admission.k8s.gatekeeper.sh
rego:|
package k8sallowedrepos
violation[{"msg": msg}] {
container := input.review.object.spec.containers[_]
satisfied := [good| repo = input.parameters.repos[_] ; good = startswith(container.image, repo)]
not any(satisfied)
msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos])
}
violation[{"msg": msg}] {
container := input.review.object.spec.initContainers[_]
satisfied := [good| repo = input.parameters.repos[_] ; good = startswith(container.image, repo)]
not any(satisfied)
msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos])
}
Contraintes OPA :
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
name: repo-is-openpolicyagent
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
parameters:
repos:
- "<ALLOWED_IMAGE_REPO>"
Sécurisation renforcée NSA/CISA : Mutations OPA :
L'exemple suivant utilise la mutation OPA pour définir allowPrivilegeEscalation sur false si elle est manquante dans la spécification d'espace.
apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
name: allow-privilege-escalation
spec:
match:
scope: Namespaced
kinds:
- apiGroups: ["*"]
kinds: ["Pod"]
excludedNamespaces:
- kube-system
applyTo:
- groups: [""]
kinds: ["Pod"]
versions: ["v1"]
location: "spec.containers[name:*].securityContext.allowPrivilegeEscalation"
parameters:
pathTests:
- subPath: "spec.containers[name:*].securityContext.allowPrivilegeEscalation"
condition: MustNotExist
assign:
value: false
La CNI Antrea est utilisée dans ce guide pour la sécurisation renforcée du réseau, car elle fournit un contrôle précis des stratégies réseau à l'aide de niveaux et la possibilité d'appliquer une stratégie de sécurité à l'échelle du cluster à l'aide de ClusterNetworkPolicy.
Open Policy Agent (OPA) est utilisé à la place des stratégies de sécurité d'espace, car elles étaient obsolètes dans Kubernetes 1.21.
Les superpositions ytt, les stratégies réseau et les stratégies OPA sont créées afin de faciliter la désactivation des contrôles de sécurisation renforcée pour certaines charges de travail par les administrateurs du cluster. Nous vous conseillons de ne pas vous retirer complètement des pratiques de sécurisation renforcée et d'isoler les charges de travail dans les espaces de noms dans lesquels ces contrôles de sécurisation renforcée ne sont pas appliqués. La désactivation des contrôles de sécurisation renforcée dépend également de la propension au risque du déploiement TKG.
