3V0-24.25 IT Architectures, Technologies, Standards

IT Architectures, Technologies, Standards Detailed Explanation

1. Core IT Architecture Concepts

1.1 Architectural Views

Architectural views help you understand a complex IT system from different angles. No single diagram can describe an entire platform, so architects divide the system into several perspectives. Each perspective focuses on specific information while ignoring unnecessary details.

Logical architecture

The logical architecture illustrates major functional components and how they interact. It avoids details such as IP addresses, VLAN IDs or physical cabling. Instead, it highlights what talks to what and how data flows through the environment.

In a VMware Cloud Foundation (VCF) environment with vSphere Kubernetes Service (VKS), a logical architecture often includes:

• Management Domain – hosting SDDC Manager, management vCenter, NSX Manager.

• Workload Domains – where business workloads run, including VMs and Kubernetes clusters.

• Supervisor Cluster – Kubernetes control plane integrated with vSphere.

• NSX – providing virtual networking and security policies.

• vSAN or shared storage – providing datastores for VMs and container volumes.

Logical architecture helps learners answer questions such as:

• Which components communicate with each other?

• How do workloads consume compute, storage and network resources?

• How do management tools integrate with the infrastructure?

Physical architecture

Physical architecture describes the actual hardware and wiring that support the logical design. It covers all real-world, tangible components:

• Server hardware (ESXi hosts)

• Racks and physical layout

• Top-of-Rack (ToR) and aggregation switches

• Cabling paths and redundancy

• Storage devices and network uplinks

• Power distribution and placement considerations

A physical architecture maps the logical structure onto real hardware. For example:

• A “Workload Domain cluster” may correspond to six physical ESXi hosts placed across two racks.

• Uplink connections might use 25GbE links from each host to redundant ToR switches.

• Storage may rely on NVMe-based vSAN devices configured across the hosts.

This view helps users understand capacity, fault domains, and failure scenarios.

Conceptual architecture

A conceptual architecture expresses the system at a high, business-oriented level. It avoids any product names or technical specifics. Instead, it describes the purpose of the platform and the capabilities it must deliver.

Example conceptual statement:

“Provide a private cloud that supports virtual machines and containerized applications,
offers centralized management, and enables self-service provisioning.”

Conceptual architecture typically uses terms like:

• Compute

• Storage

• Network

• Security

• Automation

• Governance

It explains what the platform must achieve, not how it achieves it.

Solution architecture

Solution architecture represents the complete end-to-end design that delivers the final system. It links every layer from business requirements to physical implementation. A solution architecture includes:

• Requirements analysis

• Conceptual, logical, and physical views

• Technology selections (e.g., VCF, vSphere, NSX, vSAN)

• Integration with external systems such as:

  • Identity providers (AD/LDAP)

  • Monitoring tools

  • Backup and recovery solutions

  • CMDB and ticketing systems

  • DevOps CI/CD platforms

Its purpose is to ensure the final deployed solution meets the business, technical, and operational needs.

1.2 Architecture Patterns

N-Tier / Layered architectures

N-Tier architecture divides an application into layers, each focused on a specific role. A classic 3-tier model includes:

• Presentation layer – user interfaces, APIs

• Application layer – business logic and processing

• Data layer – databases and persistent storage

In VCF + VKS environments:

• The presentation layer may run as Kubernetes services or API gateways.

• The application layer may consist of microservices deployed as pods.

• The data layer may use databases on VMs or StatefulSets using vSAN-backed persistent volumes.

This pattern improves scalability, maintainability, and separation of concerns.

Microservices & Cloud-Native

Microservices break large applications into independent, self-contained services. Each service:

• Performs one function

• Is developed and deployed independently

• Communicates through APIs

• Scales individually

A cloud-native environment such as VKS enhances microservices by providing:

• Automated orchestration (Kubernetes)

• Self-healing (pod restarts)

• Service discovery

• Declarative configuration

• Horizontal scaling

This pattern influences all areas of design:

• Networking – many small services must communicate internally

• Observability – logs, metrics, and traces must be aggregated

• Security – strong identity, least privilege, and mTLS for service-to-service communication

• CI/CD – frequent automated deployments

Cattle vs Pets

This concept helps shape how workloads should be managed:

• Pets

  • Unique, manually managed systems (e.g., a special database server)

  • Administrators repair them when they fail

  • Traditionally common in monolithic VM environments

• Cattle

  • Replaceable, identical instances (e.g., pods or multiple web service VMs)

  • When one fails, it is automatically replaced

  • Kubernetes and cloud-native principles strongly encourage this model

In VKS:

• Pod-based microservices behave as cattle.

• Some stateful services may remain pets, but architects aim to minimize such cases.

Scale-up vs Scale-out

Two approaches to increasing capacity:

• Scale-up

  • Add more CPU or RAM to an existing node

  • Useful for legacy or monolithic applications

• Scale-out

  • Add more nodes (ESXi hosts, Kubernetes workers)

  • Supported natively by Kubernetes and vSphere clusters

  • Enables better resilience and rolling upgrades

Modern cloud and Kubernetes platforms strongly prefer scale-out due to improved fault tolerance and flexibility.

2. IT Infrastructure Technologies

2.1 Compute Virtualization

Compute virtualization allows physical server hardware to be divided into multiple isolated execution environments called virtual machines (VMs). VMware vSphere uses the ESXi hypervisor to provide this capability.

Hypervisor basics

A hypervisor is a specialized operating system that abstracts physical compute resources—CPU, memory, storage, and network—and presents them as virtual hardware to VMs.

Key concepts include:

• vCPU
  A virtual CPU assigned to a VM. ESXi schedules vCPUs onto physical CPU cores.

• vNUMA (Virtual Non-Uniform Memory Architecture)
  Ensures large VMs align with physical NUMA boundaries for optimal performance.

• CPU overcommit
  ESXi allows more vCPUs to be allocated than physical cores, beneficial for mixed workloads. However, excessive overcommit increases CPU Ready Time and latency.

• Memory overcommit
  ESXi can allocate more virtual memory than is physically available using:

  • TPS (Transparent Page Sharing) – deduplicates identical pages

  • Ballooning – reclaims memory from idle VMs

  • Swapping – last-resort mechanism; impacts performance

These technologies improve density while maintaining performance.

Cluster features

ESXi hosts are grouped into clusters managed by vCenter, enabling advanced resource management and high availability.

• DRS (Distributed Resource Scheduler)

  • Balances VM workloads across hosts

  • Ensures resource fairness

  • Can enforce affinity/anti-affinity rules

• HA (High Availability)

  • Restarts VMs automatically when a host fails

  • Admission control ensures sufficient spare resources for failover scenarios

• vMotion

  • Live migration of a running VM between hosts

  • Zero downtime for workload mobility and maintenance

These cluster-level features form the foundational capability of modern virtual infrastructure.

Container-aware compute

In vSphere with Tanzu (VKS), compute virtualization extends beyond VMs to support Kubernetes-native workloads.

ESXi hosts in a Workload Domain can be configured as a Supervisor Cluster, which embeds Kubernetes control plane services directly into vSphere.

Workloads can run in two primary forms:

• PodVMs

  • A pod implemented as a lightweight VM

  • Offers VM-level isolation with container agility

• Tanzu Kubernetes Clusters (TKCs)

  • Full Kubernetes clusters running as guest clusters

  • Suitable for multi-team, multi-namespace environments

  • Provide dedicated worker nodes for containerized applications

This hybrid compute model enables both VMs and containers to run side-by-side in the same platform.

2.2 Storage Technologies

Reliable storage is essential for both virtual machines and container workloads. VMware environments support multiple storage models.

Local vs Shared Storage

Storage can be delivered through:

• Local storage

  • Disks inside individual ESXi hosts

  • Not shared; no support for vMotion or HA if used directly

  • Rarely used in enterprise environments except as part of vSAN

• Shared storage (recommended for production)

  • vSAN – VMware’s hyperconverged, cluster-based storage solution

  • SAN (FC/iSCSI) – centralized storage arrays

  • NFS – network file system shares

VCF strongly prefers vSAN, particularly with the ESA (Express Storage Architecture), due to superior performance and simplified management.

Storage abstractions

vSphere introduces several storage layers:

• Datastore
  A logical container for storing VM files; common types:

  • VMFS

  • NFS

  • vSAN

• vSAN Storage Policies
  Policies define storage characteristics such as:

  • Failures-To-Tolerate (FTT)

  • Checksum usage

  • Compression and deduplication

  • Striping

  • Object space reservation

Applications receive storage based on their assigned policy.

Kubernetes also introduces its own abstractions:

• PersistentVolume (PV)
  Actual persistent storage for K8s workloads.

• PersistentVolumeClaim (PVC)
  A request for storage by an application.

• StorageClass
  Defines the type of storage and maps to vSphere policies.

vSphere supports container storage through:

• First-Class Disks (FCD)

  • Managed independently from VMs

  • Used by CNS (Cloud Native Storage) for K8s volumes

Performance considerations

Storage design must consider:

• Latency – lower is better for transactional workloads

• IOPS – operations per second, important for high-volume applications

• Throughput – total data transfer capacity

• Queue depth – limits the number of outstanding I/O operations

• Read/write patterns – 70/30 workloads behave differently from 90/10 workloads

• Failure impact – rebuild operations consume I/O and can reduce performance

Proper capacity and performance planning ensures stable, predictable behavior for both VMs and containers.

2.3 Network Technologies

Networking is the backbone of any modern cloud platform. VCF and vSphere integrate with NSX to deliver advanced networking features.

Physical network

Modern data centers typically use:

• Leaf–spine architecture

  • Predictable low latency

  • All leaf switches connect to all spines

  • Highly scalable

• Redundant Top-of-Rack (ToR) switches

  • Provide resiliency for each rack

• ECMP (Equal-Cost Multi-Path) routing

  • Spreads flows across multiple links

• MLAG / vPC / MC-LAG

  • Link aggregation across two ToR switches

  • Prevents single-switch dependency

This design supports high-bandwidth, fault-tolerant operation for VCF Workload Domains.

vSphere virtual networking

Within ESXi hosts, VMware provides:

• vSphere Standard Switch (vSS)

  • Simple per-host switching

  • Used in small environments

• vSphere Distributed Switch (vDS)

  • Centralized management through vCenter

  • Preferred for production and required for VCF

vDS supports:

• Port groups

• NIC teaming

• Load-balancing algorithms (e.g., LACP, route-based on IP hash)

• Network I/O control

It forms the foundation for NSX overlay networks.

NSX (integral to VCF)

NSX provides software-defined networking:

• Overlay networking (GENEVE tunnels)

  • Abstracts networks away from physical topology

• Logical Segments

  • Virtual L2 networks for VMs and pods

• Tier-0 / Tier-1 Gateways

  • Routing architecture for north–south and east–west traffic

• Distributed Firewall (DFW)

  • Micro-segmentation at VM and pod granularity

• Load Balancer

  • Provides L4/L7 traffic management

NSX acts as the CNI (Container Network Interface) for VKS clusters and provides:

• Pod networks

• Service networks

• Ingress routing

• Network security policies

Network services for Kubernetes

Kubernetes provides its own networking abstractions:

• ClusterIP – internal-only service

• NodePort – exposes a service on each worker node

• LoadBalancer – integrates with NSX for north–south access

• Ingress – HTTP routing for multiple services under one endpoint

Additional components:

• CNI plugins – Pod networking backend (NSX in VCF)

• DNS & service discovery – usually CoreDNS

• Traffic paths

  • East–west: pod-to-pod communication

  • North–south: traffic entering/leaving the cluster

These services allow Kubernetes applications to communicate seamlessly inside and outside the cluster.

2.4 Security Technologies

Modern cloud platforms require robust security at every layer of the stack.

Identity and Access Management

Identity integrations ensure secure authentication:

• Active Directory / LDAP

• SSO identity providers

• Role-based access control (RBAC) across:

  • vSphere

  • SDDC Manager

  • NSX

  • Kubernetes

This ensures that each user or team only accesses allowed resources.

Network security

Key mechanisms include:

• Micro-segmentation using NSX DFW

  • Enforces firewall rules at VM or pod level

  • Blocks unauthorized east–west traffic

• Kubernetes NetworkPolicies

  • Define allowed pod-to-pod communication

  • Implement least-privilege networking

• Zero-trust security

  • No implicit trust between workloads

  • Strict identity validation and segmentation

Data security

Protecting data at rest and in transit:

• vSAN encryption

• VM encryption

• KMS (Key Management Server) integration

• TLS/mTLS for secure communication between services

Compliance

Enterprises often follow specific compliance frameworks:

• Hardening guides

• STIGs (Security Technical Implementation Guides)

• CIS Benchmarks

• Audit logging and traceability across:

  • vSphere

  • NSX

  • Kubernetes

Security technologies ensure the platform meets operational, legal, and regulatory standards.

3. IT Standards and Frameworks

3.1 Industry Standards

Industry standards ensure interoperability and reliable behavior across networks, storage, and security systems.

Networking

Common standards include:

• IEEE Ethernet (10/25/40/100G speeds)

• 802.1Q VLAN tagging

• 802.1p QoS

• 802.1AX LACP for link aggregation

• Routing protocols:

  • BGP

  • OSPF

  • ECMP routing

Storage

Key technologies:

• SCSI / NVMe protocols

• iSCSI and Fibre Channel SAN storage interfaces

• NFS v3/v4.1 network file systems

These define how storage devices communicate with hosts.

Security & Cryptography

Important standards:

• TLS/SSL for secure communications

• PKI (Public Key Infrastructure) certificate management

• FIPS cryptographic validation

• Common algorithms:

  • AES

  • RSA

  • Elliptic Curve Cryptography

These standards protect data integrity and confidentiality.

3.2 Architecture & Governance Frameworks

Frameworks help organizations manage IT systems consistently.

• ITIL

  • Incident, change, problem, and configuration management

• TOGAF

  • Architecture Development Method (ADM) for enterprise design

• COBIT

  • IT governance and control objectives

• DevOps & SRE practices

  • CI/CD automation

  • GitOps

  • SLO/SLI definitions

  • Error budgets

VCF + Kubernetes environments integrate well with DevOps due to their API-driven, declarative nature.

3.3 Cloud-Native & Kubernetes Standards

The CNCF ecosystem defines the standards and APIs used by Kubernetes-based environments.

CNCF ecosystem

• Kubernetes API portability

• CSI (Container Storage Interface)

• CNI (Container Network Interface)

• CRI (Container Runtime Interface)

• Ingress APIs and controllers

These standards allow workloads to run across different cloud providers.

Declarative configuration

Kubernetes relies on a desired state model, expressed in YAML resources such as:

• Deployments

• StatefulSets

• DaemonSets

• Services

• Ingress

Controllers continuously reconcile the actual state to match the desired state, ensuring reliability and self-healing.

IT Architectures, Technologies, Standards (Additional Content)

1. Architecture Qualities / Non-Functional Requirements (NFRs)

Non-functional requirements describe how well a system must behave, rather than what features it has. For VCF + VKS, these qualities guide almost every design decision.

1.1 Availability

Availability is about “how often is the system up and usable.”

• Design highly available architectures, such as N+1 hosts, vSAN FTT, and cross–Fault Domain deployments
  N+1 means the cluster has at least one extra host beyond what is strictly required, so if one host fails, workloads can still run.
  vSAN FTT (Failures To Tolerate) defines how many host or disk failures the storage can handle without losing data.
  Fault Domains group hosts (for example by rack) so that if an entire rack fails, the data and workloads are still available on other racks.

• Eliminate single points of failure across network, storage, management components, and control planes
  You aim to have redundancy for:

  • Physical switches and links

  • vSAN disks and controllers

  • Management VMs such as vCenter, NSX Manager (in clusters), and SDDC Manager

  • Kubernetes control planes (multiple nodes, multiple replicas)

• Support workload replicas and automatic recovery mechanisms
  For VMs, vSphere HA can restart workloads on surviving hosts.
  For containers, Kubernetes Deployments and StatefulSets can run multiple replicas so that if one instance fails, others keep serving traffic and new ones are created automatically.

1.2 Performance

Performance is about responsiveness and throughput.

• Plan resources with vNUMA alignment and avoid excessive CPU/memory overcommit
  Large VMs and nodes should be aligned with physical NUMA boundaries to avoid remote memory access penalties.
  CPU and memory overcommit are powerful but must be controlled: too much overcommit leads to CPU Ready time, ballooning, and swapping, which hurt performance.

• Consider storage performance factors: latency, IOPS, throughput, queue depth

  • Latency: how long a single IO takes

  • IOPS: how many IOs per second can be processed

  • Throughput: total data volume per second

  • Queue depth: how many IOs can be outstanding at once
    High-IOPS or latency-sensitive workloads may need faster storage devices, appropriate vSAN policies, and careful capacity planning.

• Consider network performance factors: bandwidth, latency, LAG/ECMP distributed forwarding

  • Bandwidth: link speed, for example 25 GbE

  • Latency: how long it takes for packets to travel between endpoints

  • LAG (Link Aggregation) and ECMP (Equal-Cost Multi-Path) help spread traffic across multiple links, improving throughput and resilience.
    For VCF and NSX, correct MTU and well-designed leaf–spine networks are essential.

1.3 Scalability

Scalability is the ability to grow without redesigning everything.

• Support scale-out clusters: ESXi hosts, Kubernetes worker nodes, vSAN capacity
  Scale-out means adding more nodes instead of just making a single node bigger.
  In vSphere, you add ESXi hosts to clusters.
  In Kubernetes, you add worker nodes or pods.
  In vSAN, more hosts mean more disk capacity and more performance.

• Use node-level, component-level, and microservice-level scaling models

  • Node-level: add more ESXi or K8s nodes

  • Component-level: scale a particular service instance (for example, more replicas of a web gateway)

  • Microservice-level: each microservice scales independently based on its own load

• Ensure control plane and data plane remain stable while scaling
  As you add nodes and workloads, both the Kubernetes control plane and the vSphere/NSX control planes must still perform well.
  This means designing for:

  • Reasonable cluster sizes

  • Proper API server sizing

  • Sufficient NSX and vCenter capacity

1.4 Manageability

Manageability is about how easy it is to operate the platform over time.

• Automate deployment and lifecycle management (LCM)
  Use tools such as SDDC Manager and vLCM to automate installation, patching, and upgrades.
  Reduce manual steps to decrease risk and improve consistency.

• Implement unified monitoring, log collection, and alerting
  Centralize metrics and logs from vSphere, NSX, vSAN, and Kubernetes into platforms such as VMware Aria Operations and Aria Operations for Logs.
  Set up alerts so that operations teams are notified of issues before users are impacted.

• Use tags, policy-driven configuration, and centralized APIs
  Apply policies (for example storage policies, network policies, security policies) rather than configuring each object manually.
  Use tags and labels to group resources logically (by team, environment, or application).
  Prefer automation via APIs and Infrastructure-as-Code to keep configurations repeatable and auditable.

1.5 Security

Security ensures confidentiality, integrity, and availability of data and services.

• Use RBAC, least privilege, and Pod/VM isolation strategies
  RBAC (Role-Based Access Control) is used in vSphere, NSX, and Kubernetes.
  Least privilege means each user or service only gets the permissions it absolutely needs.
  Isolation can be done through separate Namespaces, separate Workload Domains, and network segmentation.

• Use NSX Distributed Firewall, Kubernetes NetworkPolicy, mTLS, and encrypted storage
  NSX DFW enforces firewall rules at VM or pod vNIC level.
  Kubernetes NetworkPolicies control pod-to-pod and pod-to-service traffic.
  mTLS (mutual TLS) ensures encrypted communication and checks both client and server identities.
  Encrypted storage (for example vSAN encryption, VM encryption) protects data at rest.

• Integrate identity sources and implement access control auditing
  Connect vSphere and NSX to enterprise identity providers such as Active Directory.
  Log who accessed what and when, and review those logs regularly for security and compliance.

1.6 Recoverability

Recoverability is about how quickly and how completely you can restore service after a failure or disaster.

• Define DR strategies and RTO/RPO targets

  • RTO (Recovery Time Objective): how long it can take to restore service

  • RPO (Recovery Point Objective): how much data loss (in time) is acceptable
    These targets drive the choice of replication and backup technologies, and the design of DR runbooks.

• Use data backup, snapshots, and cross-site storage replication

  • Backups: regular copies of data and configuration

  • Snapshots: point-in-time copies used for fast rollback or backup seeds

  • Replication: continuously or periodically copying data to another site or region

• Plan recovery procedures for control planes and critical services
  Document and test how to recover:

  • vCenter, NSX Manager, SDDC Manager

  • Supervisor Clusters and TKCs

  • Key databases and stateful services
    Recovery processes should be rehearsed, not just written.

2. Multi-Site and Disaster Recovery Architecture Patterns

Multi-site patterns describe how you use multiple locations or zones to improve availability and DR.

2.1 Single-Region Multi-AZ Architecture

An availability zone (AZ) is a failure domain, typically a rack group or data hall.

• Use multiple AZs to improve availability and fault tolerance
  Deploy clusters across multiple AZs so that if one AZ fails, workloads continue to run in another AZ.
  This is particularly important for critical management components and Kubernetes control planes.

• Ensure cross-AZ network latency meets vSAN and Kubernetes control plane requirements
  vSAN and clustered control planes require low latency between nodes.
  Design the network so that:

  • vSAN traffic between hosts in different AZs stays within the supported latency

  • Kubernetes control plane nodes can reliably replicate state and elect leaders

2.2 Stretch Cluster Architecture

A stretched cluster spreads a single cluster across two sites, usually in the same metro area.

• Use vSAN Stretched Cluster for active-active metro deployments
  Data is synchronously replicated between the two sites, so both can serve workloads simultaneously.

• Design witness deployment and fault domains correctly
  The witness (often in a third site) stores metadata and helps decide which site remains active during a failure.
  Proper fault domain design ensures the cluster can survive the loss of one site without data corruption.

• Provide synchronous fault tolerance for VMs and container workloads
  Because writes are synchronously committed to both sites, both VM and container PVs can recover instantly at the surviving site.

2.3 Active–Passive Disaster Recovery

Active–passive DR uses a primary site for normal operations and a secondary site for emergencies.

• Use replication to provide cross-region DR (vSphere Replication, vSAN HCI Mesh, third-party tools)
  Replication asynchronously copies VM data or vSAN objects to a remote site.
  Tools such as vSphere Replication or array-based replication can be integrated with automation like Site Recovery Manager.

• Keep the DR site running at low cost until failover is needed
  The DR site typically runs minimal infrastructure until a disaster occurs.
  This reduces cost but means a longer RTO compared to stretched clusters.

• Define how to recover Kubernetes clusters under DR strategy (redeploy vs data restore)
  For Kubernetes, you can:

  • Recreate clusters from code (manifests, GitOps) and reconnect them to replicated data

  • Or replicate the entire cluster state (for example with etcd backups and PV replication)
    The choice depends on how stateful the workloads are and how strict the RPO/RTO are.

2.4 Multi-Cluster Kubernetes Topology

Multi-cluster design uses multiple Kubernetes clusters instead of a single, large cluster.

• Use multiple clusters for multi-tenancy, compliance, or geo-distribution
  Different teams, environments (Prod/Non-Prod), or regions can each have their own cluster to isolate blast radius, apply specific policies, or meet local regulations.

• Use global traffic management (GSLB/DNS) for cross-cluster access
  Users and clients often access applications via DNS names.
  Global Load Balancing and smart DNS can direct traffic to the right cluster based on geography, health, or capacity.

• Base tenant isolation on namespaces or cluster boundaries

  • Lightweight isolation: separate Namespaces within a shared cluster

  • Strong isolation: separate clusters per tenant or environment
    The choice depends on security requirements, regulatory rules, and operational complexity.

3. Compliance and Regulatory Frameworks

Compliance frameworks describe what you must do to meet legal, industry, or contractual obligations.

3.1 Security Compliance Standards

These standards focus on general security controls.

• ISO 27001 (information security management)
  Provides a framework for managing information security, including policies, risk assessment, and continuous improvement.

• PCI-DSS (payment card data security)
  Applies when processing payment card data. Requires strict controls on network segmentation, encryption, logging, and access.

• SOC 2 (service organization control reports)
  Focuses on trust principles such as security, availability, and confidentiality for service providers.

• FIPS (cryptographic compliance)
  Defines approved cryptographic modules and algorithms for government-related use.

3.2 Privacy and Data Protection Regulations

These focus on personal or sensitive data.

• GDPR (EU data protection regulation)
  Regulates how personal data of EU residents is collected, processed, and stored. Emphasizes consent, data minimization, and data subject rights.

• HIPAA (US health information protection)
  Governs the protection of healthcare information in the United States. Requires safeguards around privacy and security of health data.

• Data classification and retention policies
  Organizations classify data (for example public, internal, confidential, highly sensitive).
  Retention policies define how long data is stored and when it must be deleted.
  These drive design decisions for storage, backup, and logging.

3.3 Audit and Traceability

Auditability ensures you can prove what happened in the system.

• Log auditing, access control records, and configuration baselines
  You must collect and retain logs for:

  • Logins and access attempts

  • Configuration changes

  • Administrative actions
    Baselines describe the expected configuration so deviations can be detected.

• Compliance-driven encryption, key management, and storage policies
  Regulations may require encryption of data at rest and in transit.
  Key management must be secure and auditable.
  Storage policies must reflect compliance needs (for example, where data can physically reside).

• Automated change tracking and compliance reporting
  Tools should track changes automatically and generate reports that show compliance status over time.
  This reduces manual work and human error.

4. Cloud-Native Multi-Tenancy and Policy Enforcement

Cloud-native environments often host many teams and applications on shared platforms. Multi-tenancy and policy enforcement keep them safe and fair.

4.1 Namespace-Based Multi-Tenancy

Namespaces are a core Kubernetes abstraction for multi-tenancy.

• Use separate Namespaces per team or application
  Each Namespace can have its own permissions, quotas, and policies.
  This creates logical boundaries inside a shared cluster.

• Use ResourceQuota and LimitRange to control resource usage
  ResourceQuota limits the total CPU, memory, and storage that workloads in a Namespace can use.
  LimitRange sets default and maximum limits per pod or container.
  Together they prevent one tenant from consuming all cluster resources.

• Use RBAC to control access scope
  RBAC roles and role bindings can be applied at Namespace level.
  This ensures that a team can manage resources only in its own Namespace, not across the entire cluster.

4.2 Policy-as-Code

Policy-as-Code means you express rules in code and enforce them automatically.

• Use OPA/Gatekeeper to enforce policies such as:

  • Allowed image registries only (image source restrictions)

  • Mandatory NetworkPolicies for all Namespaces

  • Required labels and naming conventions for workloads

  • Blocking privileged containers or dangerous capabilities

Policy engines intercept resource creation requests and reject configurations that break the rules.

• Implement automated auditing and continuous compliance checks
  Policies are version-controlled and can be tested.
  The platform continually evaluates resources against policies, not just once at deployment time.
  This keeps the environment compliant even as teams deploy new workloads.

4.3 Security Isolation

Isolation is about separating tenants so they cannot interfere with each other.

• Implement Pod/VM network isolation and micro-segmentation
  NSX DFW and Kubernetes NetworkPolicies are used to restrict which pods, VMs, or services can talk to each other.
  Default-deny policies and explicit allow rules are a common pattern.

• Use storage policy isolation (different StorageClasses for different performance/security levels)
  You can define StorageClasses that map to specific vSphere Storage Policies.
  Some may have encryption, higher redundancy, or higher performance.
  Tenants or applications can be restricted to the StorageClasses appropriate for their data.

• Use Key Management Services (KMS) for centralized handling of sensitive data
  KMS systems manage encryption keys used by vSAN, VM encryption, or application-level encryption.
  Centralized key management makes it easier to audit, rotate, and revoke keys, which is important for both security and compliance.