From d5790c1252e7b9942b15a74d062001656f65c984 Mon Sep 17 00:00:00 2001 From: Hubert Siwik Date: Fri, 8 Nov 2024 07:53:09 +0100 Subject: [PATCH] Update website/content/blog/zero-trust-new-paper-announcement.md Co-authored-by: Eddie Knight Signed-off-by: Hubert Siwik --- website/content/blog/zero-trust-new-paper-announcement.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/website/content/blog/zero-trust-new-paper-announcement.md b/website/content/blog/zero-trust-new-paper-announcement.md index 1d97df63c..c44bdb95f 100644 --- a/website/content/blog/zero-trust-new-paper-announcement.md +++ b/website/content/blog/zero-trust-new-paper-announcement.md @@ -10,8 +10,8 @@ until the next release. It roughly presumed that access policy wouldn't be viola breached, and a vulnerable pod wouldn't be exploited. Up until now… After reading the TAG Security Zero Trust white paper, my understanding of this philosophy has radically changed, -and my previous view shifted into something I'd call "Limited Trust." For some, the CNCF paper introduces, and for -others reminds, of a notion of total lack of confidence, regardless of the request's source. It enforces +and my previous view has shifted into something closer to _Limited_ Trust. The emphasis I took away +was on the notion of total lack of confidence, regardless of the request's source. It enforces a "trust nothing" policy, relying on metrics that are constantly evaluated and adjusted according to the current context. Stolen credentials of a benign user or an exploited Kubernetes instance will no longer be a foothold for significant damage, as non-standard activity is expected to be quickly identified and neutralised. This is the key takeaway from the document.