Ansichten:

Wie erstelle ich manuell eine Kubernetes-Netzwerkrichtlinie für kontinuierliche Compliance?

Standardmäßig erstellt die Container Security kontinuierliche Compliance eine Kubernetes-Netzwerkrichtlinie in Ihrem Namen. Wenn Sie die Richtlinie manuell erstellen möchten, folgen Sie den unten stehenden Schritten:

Prozedur

  1. Ändern Sie den Wert von cloudOne.oversight.enableNetworkPolicyCreation zu false.
      visionOne:
    oversight:
      enableNetworkPolicyCreation: false
  2. Erstellen Sie eine Netzwerkrichtlinie mit matchLabels, die auf trendmicro-cloud-one: isolate in Ihren gewünschten Namespaces gesetzt ist.
      apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    labels:
      app.kubernetes.io/instance: trendmicro
    name: trendmicro-oversight-isolate-policy
  spec:
    podSelector:
      matchLabels:
        trendmicro-cloud-one: isolate
    policyTypes:
    - Ingress
    - Egress
    Wichtig
    Wichtig
    Die Netzwerkrichtlinie mit matchLabels trendmicro-cloud-one: isolate muss in jedem Anwendungs-Namespace vorhanden sein, um eine ordnungsgemäße Isolationsminderung durchzuführen.

Wie führe ich Helm-Chart-Operationen im Zusammenhang mit Container Security durch?

Verweisen Sie auf die folgende Tabelle, um die verfügbaren Aufgaben zu finden, die Sie mit Helm-Befehlen ausführen können.
Aufgabe
Beschreibung
Aktualisieren Sie Ihre Container Security-Bereitstellung
Um eine bestehende Installation im Standard-Kubernetes-Namespace auf die neueste Version zu aktualisieren: 
  helm upgrade \
    --values overrides.yaml \
    --namespace ${namespace} \
    trendmicro \
    https://github.com/trendmicro/visionone-container-security-helm/archive/main.tar.gz
Das obige Skript überschreibt oder setzt die Werte in der Datei overrides.yaml zurück. Wenn Sie die zuvor verwendeten Werte beibehalten möchten, verwenden Sie den Parameter -reuse-values während des Helm-Upgrades: 
  helm upgrade \
    --namespace ${namespace} \
    --reuse-values \
    trendmicro \
    https://github.com/trendmicro/visionone-container-security-helm/archive/main.tar.gz
Aktivieren oder Deaktivieren einer bestimmten Komponente
Bestimmte Komponenten des Container Security Helm-Diagramms können individuell aktiviert oder deaktiviert werden, indem eine Overrides-Datei verwendet wird. Zum Beispiel können Sie die Laufzeitsicherheitskomponente aktivieren, indem Sie das Folgende in Ihre overrides.yaml-Datei aufnehmen:
  visionOne:
    runtimeSecurity:
      enabled: true
Laufzeitsicherheit auf AWS Bottlerocket aktivieren
Standardmäßig verwendet AWS EKS Auto Mode Knoten mit dem Bottlerocket-Betriebssystem. Bevor Sie Container Security in einem Auto Mode-Cluster bereitstellen, führen Sie Runtime Security auf AWS Bottlerocket-Knoten aus, indem Sie diese Konfigurationen in Ihrer overrides.yaml-Datei hinzufügen:
securityContext:
  scout:
    scout:
      allowPrivilegeEscalation: true
      privileged: true

Wie sammle ich Protokolle für Fehlerbehebungszwecke?

Bei der Fehlerbehebung eines Problems stehen Ihnen mehrere Protokolle zur Verfügung, die Sie verwenden können.

Zugriffsprotokolle

Die meisten Probleme können mithilfe der Anwendungsprotokolle untersucht werden. Auf die Protokolle kann mit kubectl zugegriffen werden. Sie können auf die Protokolle zugreifen für die
  • Admission-Controller mit folgendem Befehl: 
    kubectl logs deployment/trendmicro-admission-controller --namespace ${namespace}
  • Laufzeitsicherheitskomponente mit dem folgenden Befehl verwenden, wobei der Container einer der scout oder falco sein kann: 
     kubectl logs daemonset/trendmicro-scout --namespace ${namespace} -c
     ${container}
  • Oversight-Controller (Kontinuierliche Compliance-Policy enforcement) mit dem folgenden Befehl verwenden: 
     kubectl logs deployment/trendmicro-oversight-controller [controller-manager |
     rbac-proxy] --namespace ${namespace}
  • Verwenden Sie den Controller mit folgendem Befehl: 
     kubectl logs deployment/trendmicro-usage-controller [controller-manager | rbac-proxy]
     --namespace ${namespace}

Supportprotokolle sammeln

Wenn Sie einen Supportfall eröffnen, reproduzieren Sie das Problem mit aktiviertem Debug-Logging und fügen Sie das Debug-Log-Paket bei. Das Log-Paket hilft Ihrem Support-Anbieter, Probleme zu debuggen, insbesondere solche, die mit In-Cluster-Komponenten oder Kommunikation zusammenhängen. Ein Skript zur Protokollsammlung steht Ihnen zur Verfügung unter Trend Micro.
Verwenden Sie die folgenden Schritte, um das Debug-Logging zu aktivieren:
  1. Setzen Sie das logConfig.logLevel auf debug in der Datei overrides.yaml und aktualisieren Sie das Helm-Chart. 
    logConfig:
  logLevel: debug
  2. Reproduzieren Sie das Problem und sammeln Sie Protokolle mit dem folgenden Befehl: 
    ./collect-logs.sh
Die folgenden Umgebungsvariablen werden für die Protokollsammlung unterstützt:
Umgebungsvariable Beschreibung Standard
VERÖFFENTLICHEN Helm-Release-Name trendmicro
NAMESPACE Der Namespace, in dem das Helm-Chart bereitgestellt wird Aktueller Namensraum in kubeconfig deklariert. Wenn keine Namensraumeinstellung in kubeconfig vorhanden ist, wird trendmicro-system verwendet.

Warum erhalte ich eine '401 Unauthorized'-Meldung bei API-Aufrufen?

Dies liegt normalerweise daran, dass Sie keinen API-Schlüssel erstellt haben, um Ihre Anfragen mit Container Security zu authentifizieren. Informationen zum Erstellen und Verwenden eines Trend Vision One API-Schlüssels finden Sie unter Abrufen eines API-Schlüssels.
Deprecated: Informationen zum Erstellen und Verwenden eines Legacy-API-Schlüssels finden Sie in der Workload Security API-Schlüssel-Hilfe.

Erfordert Container Security eingehenden Netzwerkzugriff auf meinen Kubernetes-Cluster?

Container Security erfordert derzeit keinen eingehenden Netzwerkzugang und es müssen keine zusätzlichen IP-Adressen zu den eingehenden Firewall-Regeln hinzugefügt werden. Die Kommunikation vom Admission Controller wird nur ausgehend über den HTTPS-Port 443 initiiert.

Werden reguläre Ausdrücke beim Erstellen von Richtlinien unterstützt?

Wir unterstützen die Schlüsselwörter "enthält" und "beginnt mit" für Image-Registry, Name und Tag in der ersten Version. Dies bietet eine grundlegende Schnittstelle für reguläre Ausdrücke.

Benötigt jeder Kubernetes-Cluster seinen eigenen Admission Controller?

Ja. Jeder Kubernetes-Cluster sollte seinen eigenen Admission Controller haben. Bei Bedarf können Sie die gewünschten Replikate skalieren. Der Standardwert ist 1.

Wird die Validierung von Admission-Control-Webhooks dazu führen, dass Container Security die Konfiguration eines Containers ändert?

Nein. Es überprüft nur, ob eine Bereitstellungsanforderung in einer Richtliniendefinition erlaubt oder abgelehnt wird.

Während der Validierungsphase, wenn Sie kubectl apply -f <...> ausführen, fragt der Admission Controller die Container Security ab? Falls ja, wird ein lokaler Cache für jede Abfrage verwendet?

Ja. Der Admission Controller fragt Container Security jedes Mal ab, wenn eine Überprüfungsanfrage in Kubernetes erfolgt, sowohl bei einem kubectl create als auch bei einem kubectl apply.
Es wird kein lokaler Cache für Abfragen oder Richtlinien verwendet, um sicherzustellen, dass die Richtlinie immer auf dem neuesten Stand ist.
Standardmäßig werden Überprüfungsanfragen aus dem kube-system-Namespace nicht an Container Security weitergeleitet. Weitere Informationen finden Sie in der YAML-Datei des Admission Controllers.

Wofür wird die Telemetrie in Container Security verwendet? Welche Art von Daten sendet die Zugriffskontrolle?

Weitere Informationen zur Datenerfassung und Telemetrie finden Sie im Hinweis zur Datenerfassung von Trend Vision One Container Security.

Wann sollten Sie die Replikatanzahl für den Admission Controller erhöhen?

Erwägen Sie, die Replikatanzahl für den Admission Controller in großen Umgebungen zu erhöhen, in denen viele Admission-Anfragen gleichzeitig auftreten können. Admission-Anfragen treten auf, wenn ein Pod seine Replikatanzahl skaliert, neue Bereitstellungen erfolgen usw.

Wie fügt man Pods mit mehreren Containern zu den Ausnahmen hinzu?

Pods mit mehreren Containern sollten Ausnahmen für alle darin enthaltenen Container haben. Container Security erlaubt die Zulassungsanfrage nur, wenn alle angeforderten Container keine Richtlinienregel verletzen oder die Ausnahmekriterien erfüllen.

Warum wird mein Pod nicht vom Netzwerkzugriff isoliert?

Wenn Sie die Aktion „Isolieren“ in Ihrer Continuous Compliance-Richtlinie oder Laufzeitregeln verwenden, muss der Kubernetes-Cluster, in dem die geschützten Ressourcen ausgeführt werden, Kubernetes-Netzwerkrichtlinien aktiviert haben. Um Kubernetes-Netzwerkrichtlinien zu aktivieren, installieren Sie ein Netzwerk-Plugin mit NetworkPolicy-Unterstützung mithilfe der bereitgestellten Anleitung im Helm-Chart-README.

Warum werden Schwachstellen nicht in der Sicherheitslückenansicht angezeigt?

In diesem Abschnitt werden einige häufig auftretende Probleme beim Laufzeitscannen behandelt und wie man sie beheben kann.
Scanner-Pods werden mit einem OOMKilled-Status beendet:
  • Der Status des Scanner-Pods kann mit Tools wie kubectl beobachtet werden. In diesem Fall könnte das folgende Protokoll durch Ausführen beobachtet werden
    kubectl describe nodes: 
                     Memory cgroup out of memory: Killed process xxxxx (sbom-job)
  • Während des normalen Betriebs löst jedes einzigartige Bild, das in Ihrem Cluster bereitgestellt wird, einen Scanner-Pod aus. Dieser Scan-Auftrag erzeugt ein Software-Stückverzeichnis (SBOM) für das bereitgestellte Bild, und das SBOM wird zur weiteren Analyse an Trend Vision One gesendet. Wenn das erzeugte SBOM größer ist als das standardmäßige maximale Speicherlimit des Scan-Auftrags, wird der Pod mit einem OOMKilled-Status beendet. Außergewöhnlich große Bilder (wie z. B. Bilder für maschinelles Lernen) könnten zu außergewöhnlich großen SBOMs führen. Um dieses Problem zu beheben, können Sie das standardmäßige maximale Speicherlimit des Scan-Auftrags in Ihrer Helm-Overrides-YAML-Datei (normalerweise overrides.yaml) überschreiben:
    visionOne:
    bootstrapToken: <BOOTSTRAP_TOKEN>
    endpoint: <ENDPOINT>
    vulnerabilityScanning:
        enabled: true
resources:
    scanner:
        limits:
            memory: 1024Mi
  • Um die neue Konfiguration anzuwenden, führen Sie den helm upgrade-Befehl aus. Wenn das Problem weiterhin besteht, sollten Sie in Betracht ziehen, den Speicher des Scanners erneut zu erhöhen (zum Beispiel 2048Mi).
Entdeckte Schwachstellen verschwinden aus der Sicherheitslückenansicht:
  • Die Ansicht der Sicherheitslücken beim Laufzeitscanning ist derzeit eine Live-Darstellung der Schwachstellen in Ihrem Cluster. Sobald eine Sicherheitslücke nicht mehr im Cluster aktiv ist (der anfällige Container wird beendet), wird sie sofort aus der Sicherheitslückenansicht entfernt.

Kann ich mehrere Durchsuchungswerkzeuge in meinem Cluster installieren?

Es wird empfohlen, in jedem Cluster nur ein Scantool einzuschließen, da mehrere gleichzeitig laufende Tools unvorhersehbares Verhalten verursachen können, bei dem beide Tools kontinuierlich die Pods des jeweils anderen durchsuchen. Wenn diese Situation nicht vermeidbar ist, können Sie den Namespace des anderen Scantools von Container Security-Scans ausschließen, indem Sie Folgendes zu Ihrer Overrides-Datei hinzufügen:
visionOne:
exclusion:
namespaces: [list, of, namespaces]
Es wird auch empfohlen, den Namespace, in dem Sie Container Security installiert haben, von der Überprüfung durch das andere Scan-Tool auszuschließen.

Wann sollte ich die maximale Gleichzeitigkeit für die Vulnerability Scanner-Pods erhöhen?

Große Cluster könnten davon profitieren, die standardmäßige maximale Gleichzeitigkeit für die Vulnerability Scanner-Pods zu erhöhen, um schnellere Scan-Ergebnisse zu erzielen, indem mehr Ressourcen Ihres Clusters genutzt werden. Das Gleichzeitigkeitslimit der Scanner-Pods soll die Ressourcennutzung der Container Security innerhalb Ihres Clusters einschränken. Wenn das Gleichzeitigkeitslimit beispielsweise auf 5 gesetzt ist, können maximal 5 einzigartige Images gleichzeitig gescannt werden. Die Änderung des Gleichzeitigkeitslimits der Scanner-Pods kann über Ihre Overrides-Datei erfolgen:
visionOne:
scanManager:
maxJobCount: 15
Wenn Sie das Gleichzeitigkeit-Limit für die Vulnerability Scanner-Pods erhöhen, stellen Sie bitte sicher, dass Ihr Cluster über genügend Ressourcen verfügt, um die zusätzlichen Scanner-Pods zu bewältigen. Sie können die Standardressourcenanforderungen für jeden Scanner-Pod ändern, indem Sie den Wert maxJobCount im Abschnitt scanManager des Helm-Diagramms ändern.

Wie sammle ich ECS-Scout-Servicelogs?

Um Protokolle effizient vom ECS Scout-Dienst zu sammeln, befolgen Sie die folgenden Schritte:

Prozedur

  1. Greifen Sie auf den Dienst zu, indem Sie zu Ihrem ECS-Cluster navigieren und den Dienst trendmicro-scout auswählen.
  2. Klicken Sie auf die Registerkarte Protokolle.
  3. Wenden Sie Container- und Zeitfilter an, um Ihre Suche zu verfeinern und sich auf die neuesten Protokolle zu konzentrieren, die für Ihre Analyse relevant sind.
  4. Um die Protokolle weiter zu analysieren, klicken Sie auf View in CloudWatch. In CloudWatch haben Sie die Möglichkeit, die Protokolle im CSV-Format für eine detaillierte Untersuchung und Archivierungszwecke herunterzuladen.

Wie ziehe ich Bilder aus einem privaten Register?

Standardmäßig speichert Container Security öffentliche Container-Images in der Amazon ECR Public Gallery und zieht diese Images in Cluster, wie im Helm-Chart definiert. Die Verwendung eines privaten Registrys ermöglicht Image-Pulls ohne Geschwindigkeitsbegrenzung und erlaubt es, Container-Images so zu speichern, dass sie den besten Praktiken des Unternehmens entsprechen.
Um Bilder aus einem privaten Registry abzurufen, verwenden Sie die folgenden Schritte:
Hinweis
Hinweis
Die folgenden Schritte verwenden ein privates Amazon Elastic Container Registry (ECR) als Beispiel, aber der Prozess variiert je nach verwendetem Container-Registry.

Prozedur

  1. Befolgen Sie die Anweisungen im Amazon-Benutzerhandbuch (Schritte 1 bis 8) um eine Pull-Through-Cache-Regel (AWS Management Console) für Amazon ECR Public zu erstellen.
  2. Ändern Sie die Helm-Überschreibungsdatei, um Ihre private ECR-Registry-URL, den Projektnamen und das Image-Pull-Secret im folgenden Format zu verwenden:
    images:
  defaults:
    registry: <your-private-registry>
    project: <prefix-path>
    imagePullSecret: <pull-secret-if-needed>
    Beispiel:
    images:
  defaults:
    registry: <aws-account>.dkr.ecr.us-east-1.amazonaws.com
    project: <namespace>/trendmicro/container-security
    imagePullSecret: <ecr-cred>
    Tipp
    Tipp
    Sie können den Befehl helm install oder helm upgrade verwenden, um die Werte Ihrer Helm-Overrides-Datei zu ändern.

Warum beendet sich der Sidecar-Container mit Code 137 in AWS Fargate?

In AWS Fargate, wenn der wesentliche Container einer Aufgabe normal stoppt (entweder seinen Prozess beendet oder sauber beendet), initiiert AWS automatisch das Herunterfahren der Aufgabe, indem alle anderen Container in der Aufgabe gestoppt werden, einschließlich der Sidecars. Wenn ein Sidecar-Container, wie zum Beispiel trendmicro-scout, während dieses Herunterfahrprozesses nicht innerhalb eines kurzen Timeout-Fensters beendet wird, sendet AWS eine SIGKILL (Signal 9) Nachricht, um den Container zwangsweise zu beenden, was zu einem Exit-Code 137 führt. Dies ist ein erwartetes Verhalten und weist nicht auf einen Fehler oder eine ungewöhnliche Beendigung des Sidecar-Containers hin.

Wie behebe ich eine Trend Vision One Container Security Argo CD-Anwendung, die während der Deinstallation im Löschzustand feststeckt?

Sie können das Skript argocd-cleanup.sh verwenden, um eine Trend Vision One Container Security Argo CD-Anwendung zu beheben, die während des Deinstallationsprozesses im Status "Löschen" feststeckt. Dieses Skript hilft, Finalizer und Ressourcen zu löschen, die die vollständige Entfernung der Anwendung verhindern. Weitere Informationen finden Sie unter Argo CD-Bereinigungsskript für Container Security.

Wie überprüfe ich die Authentizität von Trend Micro-Container-Images mit Cosign-öffentlichen Schlüsseln?

Cosign ist ein vertrauenswürdiges Werkzeug zum Signieren und Verifizieren von Containern, das Sie zur Authentifizierung von Trend Micro-Container-Images verwenden können. Dieser Verifizierungsprozess stellt sicher, dass Ihre Container-Images legitim von Trend Micro veröffentlicht wurden.
Hinweis
Hinweis
Diese Schritte dienen speziell zur Überprüfung von Trend Micro-Container-Images. Wenn Sie Ihre eigenen Container-Images mit vertrauenswürdigen öffentlichen Schlüsseln überprüfen möchten, siehe Attestatoren verwalten.
  1. Installieren Sie Cosign mit Homebrew (macOS/Linux): 
    brew install cosign
    Für andere Installationsmethoden siehe die Cosign-Dokumentation.
  2. Speichern Sie Ihren Trend Micro öffentlichen Schlüssel in einer Datei mit dem Namen cosign.pub. Zum Beispiel: 
    -----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE6N2uJjDtSNmTrfg/+GEU8ZzuKxAH
yXSc+SQdFeBb+eDpme+rNYVwf8ZuX6ii+4RhGW8IVHnyx458B2nlNrndqQ==
-----END PUBLIC KEY-----
  3. Überprüfen Sie das Container-Image mit dem gespeicherten öffentlichen Schlüssel: 
    cosign verify --key cosign.pub public.ecr.aws/trendmicro/container-security/<image-name>:<tag> --insecure-ignore-tlog
    Hinweis
    Hinweis
    Ersetzen Sie <image-name> und <tag> durch den spezifischen Trend Micro Container-Image-Namen und die Version, die Sie überprüfen möchten. Die verfügbaren Image-Namen und Tags finden Sie in der Amazon ECR Public Gallery.
  4. Sehen Sie sich die Ergebnisse der Cosign-Überprüfung an:
    • Wenn die Überprüfung erfolgreich ist, sehen Sie eine Bestätigung, dass die Signatur gültig ist.
    • Wenn die Überprüfung fehlschlägt, verwenden Sie das Image nicht. Kontaktieren Sie Trend Micro Support.