Feature Overview (aka. Goal Summary)

Provide product documentation for customer enablement of Zero Trust Networking targeted capabilities.

Goals (aka. expected user outcomes)

Zero Trust Networking assumes that everything is independently and always exposed to all potential threats, and provides a set of capabilities to mitigate those risks.

In line with White House Executive Order 14028: "Improving the Nation's Cybersecurity", OpenShift will focus and improve its existing Zero Trust architecture to make Zero Trust Networking easier to understand and deploy.

Requirements (aka. Acceptance Criteria):

This first phase of provide Zero Trust Networking is guided by the following parameters:

• Short-term: use what we've got already
• We can't require every solution option or existing product solution, but we should optionally provide them
• For existing solutions today, it may be a matter of documentation
• Identify our gaps and provide solutions
• Gap solutions may include partnering with 3rd-party providers

The multi-team documentation effort that coalesces our existing capabilities for ZTN across relevant OpenShift product teams will address the following targeted capabilities:

• Observability for Constant, and Retrospective, Evaluation
  • The ability to observe and verify all of the things that make up ZTN. This important for intrusion detection, forensics, and is helpful for operational load management.
• Risk Assessment
  • The ability to examine policies to make it easier for people to understand and develop.
• Identification and Authentication
  • Establishing a trust relationship by verification of the identity of the other end of a connection. Management of certificate lifecycles to limit use if compromised.
• Inter-Service Authorization
  • The ability to control access to services based on request identity.
• Traffic Authentication and Encryption (e.g. mTLS)
  • The ability to ensure that traffic on-the-wire is encrypted and that the source is identifiable.
• Endpoint Security
  • Enabling trust of remote endpoint connections to, for example, ensure certified images are run on trusted hardware and policies controlling an endpoint can be established based on endpoint characteristics.
• Session validation / Session validity expiration (current session only)
  • The ability to issue short-lived tokens (perhaps even single-use) so that tokens from a compromised pod are useless elsewhere.
• Transaction-Level Verification
  • The ability to identify and authenticate individual transactions. This can include rate-limiting by source, observability, and semantic validation that a transaction is well-formed.
• Sitewide Policy Enforcement and Distribution
  **The ability to apply and govern site-wide policies. This should allow for delegation of some permissions to users and cluster administrators within defined bounds.

Use Cases (Optional):

• FedRamp and Public Sector engagement and deployments.
• Customers with regulatory requirements to demonstrate strict networking security.
• Customers wanting best practices for improving their network security.

Questions to Answer (Optional):

• Given the set of existing capabilities we document in this effort, are there any gaps or areas of improvement requiring actual code development to be followed up in future phases of Zero Trust Networking?

Out of Scope

• Actual code development, for this first phase.

Background

Zero Trust Networking (ZTN) is an information security model that assumes that all users, devices, and applications are untrusted until they are verified and authorized.
This approach requires authentication and authorization for every user, device, and application that attempts to access a network.

ZTN is designed to provide a higher level of security by limiting access to network resources based on a user's identity, device security posture, and other contextual factors. ZTN also moves from a single network perimeter to a layered defense with single, carefully controlled gateways.

Traditional security models rely on perimeter-based security, where a firewall and other security mechanisms are used to protect the network from external threats. These security measures are no longer sufficient because users and applications can access corporate data from anywhere, using any device, which makes it difficult to establish and maintain a secure perimeter.

Customer Considerations

• Though OpenShift Service Mesh naturally provides many of the targeted ZTN capabilities, we cannot require customers deploy Service Mesh for ZTN. We must provide alternative options.

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

Collateral and Additional Information

• Zero Trust Networking - OpenShift
• ZTN Goal-to-Functionality Mapping
• Zero Trust Networking Working Group - WIP Technical Alignment Document
• Zero Trust Networking (Project Compass) Notes
• What is Zero Trust?