Zero trust paper #1395
Zero trust paper #1395
Conversation
Signed-off-by: Mariusz Sabath <[email protected]>
Signed-off-by: Mariusz Sabath <[email protected]>
✅ Deploy Preview for tag-security ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Mariusz Sabath <[email protected]>
Signed-off-by: Mariusz Sabath <[email protected]>
…nto zero-trust-paper
Signed-off-by: Mariusz Sabath <[email protected]>
Signed-off-by: Mariusz Sabath <[email protected]>
Signed-off-by: Mariusz Sabath <[email protected]>
Signed-off-by: Mariusz Sabath <[email protected]>
There was a problem hiding this comment.
I dont believe this paper is ready for TOC liaison approval at this time. There are several formatting issues with the paper (such as inconsistent new lines) and the content of the paper could benefit from a significant amount of brevity in many areas that repeat or rephrase prior content. There are several areas of content that make leaps in logic or dont quite convey the meaning of a particular topic. Additionally, several sections don't provide the reader with new or meaningful guidance and examples in order to apply Zero Trust to their environments using cloud native tooling.
I have not read the paper in its entirety due to the number of areas that would greatly benefit from additional refinement by the authors. The paper is sorely needed, and i appreciate the time and effort by the contributors in putting this draft together for an initial review and feedback.
community/resources/zero-trust-whitepaper/v1/cloud-native-zero-trust-whitepaper.md
Outdated
Show resolved
Hide resolved
|
|
||
| Contrary to what the name might suggest, the real world application of “Zero Trust” is far more nuanced than simply *trusting nothing*. The Zero Trust defense strategy assumes that the internal network is not to be trusted. This contrasts with a perimeter-based defense, which is designed to construct a trustworthy internal network. Instead, we can introduce measures to evaluate trustworthiness, then use such evaluations to control the network communications and its connected devices. | ||
|
|
||
| While many of the well-worn concepts behind Zero Trust apply to *any* system, there remains a gap with regards to discussing Zero Trust from a Cloud Native perspective. This document seeks to codify the philosophy alongside an ideal design for implementing it in a Cloud Native system. |
There was a problem hiding this comment.
I would argue that none of the concepts in Zero Trust are well-worn and that it is still a challenge to apply them to any system, thus why there remains gaps in approach Zero Trust with cloud native in mind. If it were so well-worn, this paper would have been published in 2022 and many government agencies would not be releasing their ZT strategies in 2024.
| While many of the well-worn concepts behind Zero Trust apply to *any* system, there remains a gap with regards to discussing Zero Trust from a Cloud Native perspective. This document seeks to codify the philosophy alongside an ideal design for implementing it in a Cloud Native system. | |
| Zero Trust concepts have been around for a while, however there continues to be a gap in how industry can effectively adopt and apply them across all systems and applications in use, Cloud Native is no exception. This document seeks to codify the philosophy alongside a recommended design for implementing Zero Trust principles in Cloud Native systems and applications. |
There was a problem hiding this comment.
I would argue that the concepts are well-worn, while I agree that it is still a challenge to apply them to any system :)
I.e. Many of the concepts defining how to build a ZTA are here with us for quite a while - not suggesting that we have the tools and mechanisms to implement them.
At the same time, I am also perfectly ok with the suggested change - so I would vote to accept it as is.
There was a problem hiding this comment.
@TheFoxAtWork are you OK with us keeping it as is, or you like this to be changed per your suggestion?
BTW I tried to find you at the conference to say "hello", but no luck...
There was a problem hiding this comment.
We can mark this comment as resolved. @mrsabath apologies i missed you, KCCNs are always my busiest time.
community/resources/zero-trust-whitepaper/v1/cloud-native-zero-trust-whitepaper.md
Outdated
Show resolved
Hide resolved
|
|
||
| The authors have compiled their experience and research findings into a set of principles and approaches. While many of the concepts herein are a distillation of past publications, extending those findings has led to a new proposal to standardize the generation and utilization of “Confidence Levels” as a data type. Confidence Levels quantify the trustworthiness of entities within a system, allowing for more dynamic and responsive security measures. | ||
|
|
||
| Confidence Levels can be produced by “Active Observers,” a previously unnamed category of tools. Active Observers continuously monitor and analyze the security-related attributes and behaviors of entities in the system to quantify trustworthiness. |
There was a problem hiding this comment.
perhaps it is later, but this doesnt detail why active observers are being recommended, it just introduces the concept. Why are these beneficial specifically in cloud native for achieving Zero Trust and not in the broader technology ecosystem? Do they fill a un-noted gap that is critical to ZT implementation? Highly recommend adding in the illuminating moment that drives us towards active observers here so the reader is prepared for its more robust introduction later.
There was a problem hiding this comment.
@TheFoxAtWork, We are not stating or suggesting that active observers are beneficial specifically in cloud native for achieving Zero Trust - these are beneficial in the broader technology ecosystem.
We do state that “Active Observers,” are a previously unnamed category of tools - i.e. we help name and better define such tools and help explain how they are being used. There are mentioning of such capabilities in previous ZT docs, we take this one step further.
There was a problem hiding this comment.
@davidhadas okay that makes sense. So for the purposes of this section in the abstract, providing brief context as to why active observers are beneficial in the broader technology ecosystem, specifically to Zero trust is what is missing.
from the reader's perspective, confidence levels are new and they are a data type. they are produced by active observers. This details what an active observer is, but doesnt explain it in the context of ZT here, why they're needed just that there are a category of unnamed tools. If they are described in previous ZT docs, we dont link or refer to them here or why they're beneficial.
Does this make sense? Its the "how" that is missing here for the reader. Essentially - the reader is introduced to this new thing, they dont know why they should care - as an author or contributor, it is our duty to elaborate as to the why they should care, how active observers are of benefit, either for ZT or for the ecosystem in its entirety.
| <td>Assume a Breach | ||
| </td> | ||
| <td>Every Image Includes Vulnerabilities | ||
| </td> | ||
| </tr> | ||
| <tr> | ||
| <td>2 | ||
| </td> | ||
| <td>Assume a Breach | ||
| </td> | ||
| <td>Every Service is Vulnerable | ||
| </td> | ||
| </tr> | ||
| <tr> | ||
| <td>3 | ||
| </td> | ||
| <td>Assume a Breach | ||
| </td> | ||
| <td>Every Service will be Exploited | ||
| </td> | ||
| </tr> | ||
| <tr> | ||
| <td>4 | ||
| </td> | ||
| <td>Assume a Breach | ||
| </td> | ||
| <td>The Cluster Network is Hostile | ||
| </td> | ||
| </tr> | ||
| <tr> | ||
| <td>5 | ||
| </td> | ||
| <td>Assume a Breach | ||
| </td> | ||
| <td>Clients will Send Malicious Requests |
There was a problem hiding this comment.
The heading/titling structure here does not match with that of Always Verify, which has a secondary phrase enhancement. Recommend either eliminating the enhancing phrase or adding an enhancing phrase to the Assume a Breach. It doesnt appear to add substantial value however and given the table is quite simple in its content, you can increase its value by providing a more clear example of what is meant or pose questions to the reader to have them consider the context:
Assume a breach: Clients will send malicious requests. In the case a client begins sending malicious requests, are you servers capable of authenticating the client and verifying its authorization to connect prior? In the event that a valid, authorized client is compromised, are your servers capable of validating the input in the event it is malformed? what about sending too many requests? Do you have detection rules in place to identify unusual behaviour by clients?
There was a problem hiding this comment.
I would further recommend linking each item in the table to the corresponding H3 below in the event a reader wishes to jump down into that content.
There was a problem hiding this comment.
It seems repetitive to spell out each one in the table and also in the below H3 sections.
I believe the second column help connect the principles to the NIST Tenet which is part of covering where these principles come from.
@mrsabath can we manually add links to the table?
And do we also need it in the doc?
There was a problem hiding this comment.
Yes, we can do them manually, but we have to make sure that any changes in this document are also reflected in the Google Doc that would be used for rendering the PDF, so I suggest ONLY ONE PERSON does the updates in both places, otherwise we will get out of sync quickly. I am happy to do them, but I need to know exactly what to update. Since I am on KubeCon too, the edits might be delayed...
There was a problem hiding this comment.
@mrsabath
We continue to rely on you for making the changes and keeping the two documents inline.
Where a reviewer made a specific edit suggestion, I am trying to help by reading the text with the suggestion and adding a thumb up for support.
Where a reviewer commented without a specific edit suggestion, I am trying to either add my own specific edit suggestion or commenting that it may be preferable not do a change.
There was a problem hiding this comment.
I realized what you did @davidhadas and thank you for that. I really appreciate your help with managing the edits. I think I merged all the suggestions that were approved by you unless they require some further explanation or investigation.
There was a problem hiding this comment.
Like this one: #1395 (comment)
Are we keeping it as is?
There was a problem hiding this comment.
I think the text on that comment can stay as is, but lets see if others will also see a need for change and what that change may be.
community/resources/zero-trust-whitepaper/v1/cloud-native-zero-trust-whitepaper.md
Outdated
Show resolved
Hide resolved
community/resources/zero-trust-whitepaper/v1/cloud-native-zero-trust-whitepaper.md
Outdated
Show resolved
Hide resolved
community/resources/zero-trust-whitepaper/v1/cloud-native-zero-trust-whitepaper.md
Outdated
Show resolved
Hide resolved
| ### 3. Every Service Will be Exploited | ||
|
|
||
| Organizations must adopt the perspective that any cloud native deployed service is susceptible to exploitation at some point. When deploying a service, it is essential to assume that it may be exploited through various vectors, including internal malware infiltration, insider misuse, or unauthorized access to credentials or control systems. | ||
|
|
||
| This assumption necessitates a comprehensive and proactive approach to security, wherein continuous monitoring and rapid response mechanisms are integral components. By acknowledging the inevitability of exploitation attempts, organizations can better prepare to detect and mitigate threats promptly, minimizing potential damage. |
There was a problem hiding this comment.
I'm reading through these and trying to understand why we've chosen to talk about these challenges at a high level. We're not detailing anything about zero trust to the benefit of the reader.
for example, in the event a service is exploited, what specific capabilities, features, and tooling do we as cloud native security professionals recommend? Runtime detection tools assist in identifying if a host or workload was exploited. Tools that provide remote attestation have the ability to measure the integrity of files to detect if it has been tampered with.
these are specific recommendations we should be providing throughout this area of the paper that provide value to the reader.
There was a problem hiding this comment.
We cover this later in the paper -
Here we spell out the principles to follow (adding one more detail to the overall ZT mindset the reader should maintain) - we suggest that the reader would consider that each and every service running on the CN may be exploited.
Later in the doc we discuss how should the reader detect such a situation and what should happen next.
There was a problem hiding this comment.
@TheFoxAtWork - Will you be ok with keeping this text as is given my comment above?
There was a problem hiding this comment.
I appreciate the explanation of where the remainder of the content can be found, however it seems like text continuously doesnt close out a concept, rather leaving many open to be picked back up later in the document. This makes it difficult for the reader to refer back to, having to navigate many sections to find the specific content rather than the actionable area.
I understand introducing these slowly and providing additional content grouped together, perhaps mentioning where in the paper the remainder of relevant content is to be found as the reader doesn't know what will be covered later? (unless they read your comment of course). This would be far simpler and still provide ease of navigation and knowledge of additional information forthcoming.
Co-authored-by: Emily Fox <[email protected]> Signed-off-by: Mariusz Sabath <[email protected]>
…-trust-whitepaper.md Co-authored-by: Emily Fox <[email protected]> Signed-off-by: Mariusz Sabath <[email protected]>
…-trust-whitepaper.md Co-authored-by: Emily Fox <[email protected]> Signed-off-by: Mariusz Sabath <[email protected]>
…-trust-whitepaper.md Co-authored-by: Emily Fox <[email protected]> Signed-off-by: Mariusz Sabath <[email protected]>
…-trust-whitepaper.md Co-authored-by: Emily Fox <[email protected]> Signed-off-by: Mariusz Sabath <[email protected]>
Update the approvals metadata heading Signed-off-by: Mariusz Sabath <[email protected]>
Replace *open-source* with *open source* Signed-off-by: Mariusz Sabath <[email protected]>
…-trust-whitepaper.md Co-authored-by: Emily Fox <[email protected]> Signed-off-by: Mariusz Sabath <[email protected]>
community/resources/zero-trust-whitepaper/v1/cloud-native-zero-trust-whitepaper.md
Outdated
Show resolved
Hide resolved
…-trust-whitepaper.md Co-authored-by: David Hadas <[email protected]> Signed-off-by: Mariusz Sabath <[email protected]>
…-trust-whitepaper.md Co-authored-by: David Hadas <[email protected]> Signed-off-by: Mariusz Sabath <[email protected]>
…-trust-whitepaper.md Co-authored-by: David Hadas <[email protected]> Signed-off-by: Mariusz Sabath <[email protected]>
…-trust-whitepaper.md Co-authored-by: David Hadas <[email protected]> Signed-off-by: Mariusz Sabath <[email protected]>
Signed-off-by: Mariusz Sabath <[email protected]>
…-trust-whitepaper.md Co-authored-by: David Hadas <[email protected]> Signed-off-by: Mariusz Sabath <[email protected]>
…-trust-whitepaper.md Co-authored-by: David Hadas <[email protected]> Signed-off-by: Mariusz Sabath <[email protected]>
Signed-off-by: Mariusz Sabath <[email protected]>
|
Can we please get an update on where this is at? I know that some folkx were tied up with KubeCon but given that people should be well rested now, I'm keen to see what we can do to move this forward |
My understanding is that we have addressed most, if not all @TheFoxAtWork 's concerns and comments. |
There was a problem hiding this comment.
I've gotten significantly further than my previous review and still have the following challenges with the content as it is presented:
- there are many topics, concepts, and ideas that are repeated multiple times throughout this paper. these should be reviewed, streamlined, and co-located to provide a complete discussion of the idea. This doesn't prevent the introduction of those concepts, but rather keeps them tighter in the overall flow and readability. Right now, the flow jumps around significantly and makes it difficult for the reader to full grasp how each of the concepts fit together in a cloud native architecture.
- there are areas of the paper that are inconsistent with one another, either in the presentation of the material, or in what specifically is being addressed/discussed. Some content is cloud native specific, some of it is not, some map non-cloud native content to cloud native attributes and characteristics, but this isn't consistent throughout. There is a lot of content that is repurposed from other sources (like NIST) instead of simply referenced and areas where references should be added so the reader can learn more. CNCF papers should always reference existing prior art rather than re-explain long standing concepts. This allows us to focus specifically on the cloud native aspects of applying a topic, idea, or implementing technical concept to these architectures.
- Some security/ZT concepts are not discussed, particularly as CNCF has projects that perform those functions, they're referenced at the end in the technologies area, but their capability isn't included, referred or mentioned in context so readers have to guess how they might achieve a specific recommendation with cloud native projects. The technologies list also includes at least one archived project.
- The vast majority of the terms mentioned at the end already have industry wide and accepted meanings, rewriting those definitions instead referencing them at the source increases the probability of inaccuracies or deviations from the original definition. Cloud Native, for example, is defined by the CNCF TOC and the definition included does not match or reference the official definition.
It is for the TOC Liaisons (@linsun @dzolo @mauilion) to review and approve the paper, regardless of adjudication status of comments. As this paper is currently presented, I do not feel it meets the expectations of due diligence in content we expect for CNCF papers.
I would suggest the following to continue to move this forward (should the liaisons, tag chairs, or authors concur - that is up to them, they may propose other options):
- substantially reduce the overall content to get the top level concepts and ideas out to the community and ecosystem, this increases the chances it will be read.
- ascertain/survey the interest and viability of the reduced content with potential readers of the community (tag security has run survey's in the past to understand gaps and needed improvements in the material provided to the ecosystem)
- incorporate feedback from the survey to reboot this paper, or should the results warrant it, set the paper reboot aside for a later date when community interest and user momentum on the topic is increased.
| **Last Reviewed**: DD MMM 2024, **PDF Published**: DD MMM 2024 **Release Version**: 1.0 | ||
|
|
||
| **TAG Sponsor Approver** [X] @eddie-knight | ||
| **TOC Liaison Approvers** [] @TheFoxAtWork [] $GITHUBHANDLE |
There was a problem hiding this comment.
| **TOC Liaison Approvers** [] @TheFoxAtWork [] $GITHUBHANDLE | |
| **TOC Liaison Approvers** [] @dzolotusky [] @mauilion [] @linsun |
These are the current TOC liaisons for TAG Security, it is their approval that is required.
|
|
||
| Contrary to what the name might suggest, the real world application of “Zero Trust” is far more nuanced than simply *trusting nothing*. The Zero Trust defense strategy assumes that the internal network is not to be trusted. This contrasts with a perimeter-based defense, which is designed to construct a trustworthy internal network. Instead, we can introduce measures to evaluate trustworthiness, then use such evaluations to control the network communications and its connected devices. | ||
|
|
||
| While many of the well-worn concepts behind Zero Trust apply to *any* system, there remains a gap with regards to discussing Zero Trust from a Cloud Native perspective. This document seeks to codify the philosophy alongside an ideal design for implementing it in a Cloud Native system. |
There was a problem hiding this comment.
We can mark this comment as resolved. @mrsabath apologies i missed you, KCCNs are always my busiest time.
|
|
||
| The authors have compiled their experience and research findings into a set of principles and approaches. While many of the concepts herein are a distillation of past publications, extending those findings has led to a new proposal to standardize the generation and utilization of “Confidence Levels” as a data type. Confidence Levels quantify the trustworthiness of entities within a system, allowing for more dynamic and responsive security measures. | ||
|
|
||
| Confidence Levels can be produced by “Active Observers,” a previously unnamed category of tools. Active Observers continuously monitor and analyze the security-related attributes and behaviors of entities in the system to quantify trustworthiness. |
There was a problem hiding this comment.
@davidhadas okay that makes sense. So for the purposes of this section in the abstract, providing brief context as to why active observers are beneficial in the broader technology ecosystem, specifically to Zero trust is what is missing.
from the reader's perspective, confidence levels are new and they are a data type. they are produced by active observers. This details what an active observer is, but doesnt explain it in the context of ZT here, why they're needed just that there are a category of unnamed tools. If they are described in previous ZT docs, we dont link or refer to them here or why they're beneficial.
Does this make sense? Its the "how" that is missing here for the reader. Essentially - the reader is introduced to this new thing, they dont know why they should care - as an author or contributor, it is our duty to elaborate as to the why they should care, how active observers are of benefit, either for ZT or for the ecosystem in its entirety.
|
|
||
| The National Institute of Standards and Technology (NIST) has been pivotal in formalizing the Zero Trust model. [NIST's guidelines on Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) outline key tenets such as continuous verification, least-privilege access, and micro-segmentation. These principles ensure that security measures are consistently applied across all network layers and endpoints, reinforcing the Zero Trust approach. | ||
|
|
||
| The history of Zero Trust started as a theoretical concept and evolved into a practical, essential cybersecurity framework. The contributions of early theorists, pioneering implementations by industry leaders, and the formalization by standardization bodies like NIST have collectively shaped the Zero Trust model, making it a cornerstone of modern cybersecurity strategies in cloud native environments. |
|
|
||
| Building on the extensive discourse surrounding Zero Trust principles over the years, two foundational tenets have been established: *Assume a Breach* and *Always Verify*. When applying these tenets to cloud native environments, we have delineated eleven governing principles. | ||
|
|
||
| To follow the tenet of *Assume a Breach*, organizations must operate as if their systems are already hacked. This mindset encourages the development and implementation of security strategies that are inherently resilient and capable of detecting, containing, and mitigating threats in real time. |
There was a problem hiding this comment.
Fair - however if the intent is to introduce these concepts to the reader, the concepts should be well introduced before detailing them later as it provides the reader with sufficient context to fully comprehend and potentially action or apply the concept fully.
| **Service Instances** are the individual services offered using containers on cloud native clusters. Securing these includes implementing DevSecOps practices to secure applications from inception through production. Adopting secure-by-design practices, robust image build methodologies, comprehensive image scanning, and secure storage are critical. Service runtime protection methods, such as behavioral monitoring, help establish Confidence Levels for services. | ||
|
|
||
| **Client Identities** refer to the unique identifiers of clients sending service requests, whether external or internal. Ensuring the security of these identities involves verifying and monitoring their behavior to form Confidence Levels. Continuous monitoring helps detect and mitigate potential threats from compromised or malicious clients. | ||
|
|
||
| **Service Requests** are the interactions initiated by clients to access services. Securing these requests involves monitoring the risks they pose and forming Confidence Levels to assess their trustworthiness. Each request must be scrutinized to prevent exploits and ensure safe interactions. | ||
|
|
||
| **Data** encompasses all the information that services handle and store. Effective data security requires categorizing data to apply appropriate security measures based on data types. This ensures that sensitive information is adequately protected. Data classification helps in enforcing policies tailored to the sensitivity and importance of the data. | ||
|
|
||
| The **Network** comprises the communication channels between clients and services. Securing the network involves protecting service requests and responses through encryption and other measures to prevent unauthorized access and data breaches. Network security encompasses measures to protect data in transit and to monitor for any suspicious activities. | ||
|
|
||
| **Access Control** refers to the policies and mechanisms that govern who can access what resources. Implementing comprehensive access control policies is essential for securing services. This includes enforcing micro-segmentation within clusters and applying granular access controls using gates in front of services. Access control decisions should consider the Confidence Levels of identities and requests, as well as the data types of both requests and responses. | ||
|
|
||
| **Automation** involves using tools and processes to manage the deployment, configuration, and auditing of cloud native components. Ensuring that zero trust principles are followed throughout these automated processes is essential. Automated removal of suspected service instances based on their Confidence Levels further enhances security. |
There was a problem hiding this comment.
How are these bespoke to cloud native? why are we calling these specific items out? with the exception of access control, cloud native concepts are not mentioned.
| *Image 2. Note that the service request sender (aka client) may be malicious. \ | ||
| The Network and Data may also be compromised.* | ||
|
|
||
| In cloud native environments, client identities may be malicious, service requests may include exploits, service instances may be compromised, data may contain vulnerabilities, and the network may be hostile. Given these potential threats, it is imperative to deploy an "Active Observer" to continuously assess the Confidence Levels of these entities. |
There was a problem hiding this comment.
This is not specific to cloud native (the phrasing on this would imply that only in cloud native environments is this true). In all environments - cloud native or otherwise - clients may be malicious (technically an identity in that context isnt malicious its how it is used), etc.
|
|
||
| To deal with a breached cloud network, we introduce Peer Identities and Secure Communication. Then, to handle breached clients, we introduce Behavior Verification enhanced Access Control. Last, to mitigate the impact of breached cloud service instances, we introduce Behavior Verification enhanced Instance Confidence Automation. Together, this creates a robust system that aims to cope with the different potential breaches. | ||
|
|
||
| At the heart of Cloud Native ZTA is the concept of identity—every ZTA entity must have a unique, verifiable identity. Traffic from unknown entities, lacking an identity which cannot be traced to its source, leaves us unable to track and control the entity in question. In this chapter, we will explain how to establish these identities, secure their communications, and ensure that the behavior of all entities is constantly scrutinized and verified. |
There was a problem hiding this comment.
any reason why we don't mention cryptographically verifiable identities that were issued after verifying the host, node, or workload's attestations? either measured boot, or file integrity measurements to increase the confidence that the identity was issued to a known good and verified instance?
We have several cloud native projects that do provide cryptographically verifiable identities, and when used with attestation tools, like Keylime, users can have greater confidence the identity they issued wasn't issued to a comprised host.
|
|
||
| ## Secure Communication | ||
|
|
||
| Zero Trust operates under the assumption that offenders may already have control over the cloud network. Therefore, a Zero Trust Architecture (ZTA) must ensure data confidentiality for communication between microservices, or between microservices and external entities. As discussed below, to achieve data confidentiality, we must verify the identity of every service and encrypt all communications. |
There was a problem hiding this comment.
| Zero Trust operates under the assumption that offenders may already have control over the cloud network. Therefore, a Zero Trust Architecture (ZTA) must ensure data confidentiality for communication between microservices, or between microservices and external entities. As discussed below, to achieve data confidentiality, we must verify the identity of every service and encrypt all communications. | |
| Zero Trust operates under the assumption that attackers may already have control over the cloud network. Therefore, a Zero Trust Architecture (ZTA) must ensure data confidentiality for communication between microservices, or between microservices and external entities. As discussed below, to achieve data confidentiality, we must verify the identity of every service and encrypt all communications. |
|
|
||
| ### Data Confidentiality | ||
|
|
||
| Every Cloud Native request, whether initiated by an internal microservice or an external client, must be performed using Transport Layer Security (TLS) to encrypt the channel. This guarantees that even if an offender intercepts the data between the client and server from the internal network, it will not gain access to the request and response data. |
There was a problem hiding this comment.
rather than specifically call out one protocol that provides encryption, identifying that the channel must be encrypted, or even better that data in transit must be encrypted ensures this paper's guidance is more applicable.
|
Hi @mrsabath and @davidhadas— Marking this as draft while there are still a high volume of comments to address. Will you be pushing forward on this to resolve the feedback from the TOC? |
|
Closing this PR per discussion with @mrsabath and @davidhadas. |
Publishing CNCF Zero Trust White Paper.
This PR replaces the original #1229 as requested by TAG Security reviewers.
The Markdown is based on Google Doc: https://docs.google.com/document/d/18w243JXhGxNgJk0SS1gT-LWUw29F8KFrc1D1F9dvfhw/edit?usp=sharing
CNCF issue: #950
This is still a draft. I just started the conversion and it requires more Markdown work and cleanup