Automated TLS certificate lifecycle management: A policy-driven framework for kubernetes security hardening

 Corresponding author: Nawazpasha Shaik Copyright © 2025 Author(s) retain the copyright of this article. This article is published under the terms of the Creative Commons Attribution License 4.0. Automated TLS certificate lifecycle management: A policy-driven framework for kubernetes security hardening Nawazpasha Shaik * Humana Inc, USA. Global Journal of Engineering and Technology Advances, 2025, 23(01), 250-257 Publication history: Received on 09 March 2025; revised on 19 April 2025; accepted on 21 April 2025 Article DOI: https://doi.org/10.30574/gjeta.2025.23.1.0110 Abstract This article presents a comprehensive framework for automating TLS certificate lifecycle management in Kubernetes environments to address critical security challenges in cloud-native applications. The proposed solution integrates policy-driven certificate management with Kubernetes native resources to enforce organizational security standards, prevent misconfigurations, and enable zero-trust security models through mutual TLS. The article implements centralized policy control that ensures compliance with industry standards while providing automated certificate issuance, rotation, and revocation mechanisms that eliminate service disruptions due to expired certificates. The article demonstrates how this approach significantly reduces the attack surface by preventing weak encryption algorithms and unauthorized service communication. The evaluation shows that enterprises implementing this framework achieve consistent TLS security governance across multi-cloud Kubernetes deployments while satisfying regulatory requirements. This article contributes to the emerging field of DevSecOps by addressing the operational complexity of maintaining robust cryptographic controls in highly dynamic container orchestration environments. Keywords: Kubernetes security; TLS certificate automation; Zero-trust architecture; Mutual TLS (mTLS); Certificate lifecycle management 1. Introduction 1.1. Background on Kubernetes Security Challenges in Cloud-Native Environments The rapid adoption of containerization and orchestration technologies has transformed modern application deployment, with Kubernetes emerging as the de facto standard for container orchestration in cloud-native environments. Despite its powerful capabilities for automating deployment, scaling, and management of containerized applications, Kubernetes presents significant security challenges that organizations must address. As Binnie and McCune [1] extensively document, Kubernetes clusters face numerous external attack vectors, including unauthorized API server access, exploitation of misconfigured RBAC policies, and compromised service-to-service communications. 1.2. The Critical Role of TLS Certificates in Securing Container Orchestration Among the critical security components in a Kubernetes infrastructure, Transport Layer Security (TLS) certificates serve as fundamental building blocks for establishing trusted communications. TLS certificates enable encrypted connections between components, authenticate service identities, and protect sensitive data in transit. Walsh [2] emphasizes that trustworthy certificate authorities are essential for maintaining the integrity of TLS implementations, as they establish the foundation of trust upon which secure communications depend. In container orchestration environments, TLS certificates protect critical pathways including API server communications, ingress controllers, service meshes, and inter-service communications. Global Journal of Engineering and Technology Advances, 2025, 23(01), 250-257 251 1.3. Overview of Certificate Management Challenges in Dynamic Kubernetes Environments Certificate management in dynamic Kubernetes environments introduces unique challenges that traditional approaches fail to address adequately. The ephemeral nature of containerized workloads, frequent deployment cycles, and dynamic scaling make manual certificate management impractical and error-prone. Organizations struggle with certificate visibility across clusters, tracking expiration dates, enforcing cryptographic standards, and maintaining consistent implementation across development, staging, and production environments. Binnie and McCune [1] identify certificate misconfigurations as a significant attack vector that malicious actors can exploit to compromise Kubernetes clusters. 1.4. Research Objectives and Significance of Automated Certificate Lifecycle Management This research aims to develop a comprehensive framework for automating TLS certificate lifecycle management in Kubernetes environments. The primary objectives include: designing a policy-driven approach to certificate management that enforces organizational security standards; developing automation mechanisms for certificate issuance, rotation, and revocation; implementing mutual TLS for zero-trust security models; and evaluating the effectiveness of the proposed framework in real-world scenarios. The significance of this work lies in addressing the operational complexity of maintaining robust cryptographic controls in highly dynamic environments while reducing the risk of service disruptions due to expired certificates. By integrating with existing Kubernetes primitives, the proposed framework seeks to enhance security without introducing additional operational burden, thereby enabling organizations to achieve both security and agility in their cloud-native deployments. 2. Review of Current Kubernetes TLS Security Practices 2.1. Analysis of Manual Certificate Management Approaches and Their Limitations Traditional certificate management in Kubernetes environments has largely relied on manual processes that present significant operational challenges. System administrators typically generate certificates using command-line tools, manually distribute them to the appropriate services, and track expiration dates through spreadsheets or calendar reminders. Michael Atighetchi, Nathaniel Soule, et al. [3] discuss how manual configuration of TLS connections introduces numerous potential failure points, including human error during certificate generation, improper private key storage, and missed renewals. These manual approaches become increasingly impractical as organizations scale their Kubernetes deployments across multiple clusters and environments. The dynamic nature of containerized workloads, with services being created and destroyed frequently, further compounds these challenges as certificate lifecycle management becomes exponentially more complex. 2.2. Survey of Existing Certificate Management Solutions for Kubernetes Several certificate management solutions have emerged to address the challenges of TLS security in Kubernetes environments. Native solutions include the Kubernetes certificates API and kubeadm, which provide basic certificate issuance capabilities but limited automation for the complete certificate lifecycle. Third-party solutions such as certmanager offer more comprehensive approaches by integrating with certificate authorities and automating issuance and renewal processes. However, as Atighetchi, Soule, et al. [3] note, these tools often lack sophisticated policy enforcement mechanisms necessary for enterprise environments with strict security requirements. While existing solutions address technical aspects of certificate issuance, they frequently overlook holistic security governance, which requires integration with organizational policies, compliance frameworks, and security monitoring systems. 2.3. Common TLS Misconfigurations and Their Security Implications TLS misconfigurations represent a significant security risk in Kubernetes environments. Common issues include the use of self-signed certificates, weak cipher suites, outdated protocol versions, and improper certificate validation. Atighetchi, Soule, et al. [3] identify that misconfigured TLS connections can lead to vulnerabilities that enable man-inthe-middle attacks, unauthorized access to sensitive data, and service impersonation. Certificate expiration remains a persistent problem, with organizations experiencing service outages when certificates expire without timely renewal. These misconfigurations often result from knowledge gaps among operators, inconsistent security practices across teams, and the absence of automated validation mechanisms that can detect and remediate issues before they impact production environments. Global Journal of Engineering and Technology Advances, 2025, 23(01), 250-257 252 Table 1 Common TLS Misconfigurations in Kubernetes Environments and Their Security Implications [3] Misconfiguration Type Security Implication Prevalence Self-signed certificates Vulnerable to MITM attacks, lacks trusted validation High Weak cipher suites Reduced cryptographic protection Medium Expired certificates Service disruption, security bypass High Improper certificate validation Authentication bypass, service impersonation Medium Inappropriate key length Vulnerable to brute force attacks Low Unrevoked compromised certificates Continued unauthorized access after breach Medium 2.4. Gap Analysis Between Current Practices and Zero-Trust Security Requirements Current certificate management practices in Kubernetes environments fall short of meeting zero-trust security requirements. Naeem Firdous Syed, Syed W. Shah, et al. [4] emphasize that zero-trust architecture demands continuous authentication and authorization for all communications, with no implicit trust granted based on network location. Existing approaches to TLS in Kubernetes typically focus on perimeter security (securing ingress and egress traffic) rather than comprehensive service-to-service authentication. Many organizations lack the infrastructure to implement mutual TLS (mTLS), where both client and server authenticate each other, which is fundamental to zero-trust models. Furthermore, current solutions often fail to provide fine-grained certificate revocation capabilities, vulnerability to certificate compromise, and mechanisms for certificate transparency and auditability. The transition to a true zero-trust model requires addressing these gaps through more sophisticated certificate management frameworks that integrate with broader identity and access management systems. 3. Architecture of TLS Protect for Kubernetes 3.1. System Design Principles and Components The TLS Protect architecture for Kubernetes is designed around core principles of security, automation, and seamless integration with existing container orchestration workflows. Drawing from the security practices outlined by Md Shazibul Islam Shamim, Farzana Ahamed Bhuiyan, et al. in the "XI Commandments of Kubernetes Security" [5], the architecture emphasizes defense-in-depth, least privilege access, and continuous validation. The system consists of several key components: a central policy engine that defines and enforces organizational TLS requirements; a certificate orchestrator that interacts with Kubernetes resources and certificate authorities; monitoring and alerting modules for certificate lifecycle events; and an administrative interface for policy management and visibility. These components work together to create a comprehensive certificate management solution that addresses the unique challenges of containerized environments. The architecture implements a control plane/data plane separation pattern, allowing for centralized policy management while distributing certificate handling across multiple clusters. 3.2. Integration Points with Kubernetes API Server and Certificate Authorities TLS Protect integrates with the Kubernetes ecosystem through multiple touchpoints to enable seamless certificate management. The primary integration is with the Kubernetes API server, leveraging custom resource definitions (CRDs) to represent certificates, issuers, and policies within the Kubernetes object model. As described in the Venafi white paper [6], this integration allows TLS Protect to monitor and respond to changes in the cluster, such as new service deployments requiring certificates. The architecture includes connectors to various certificate authorities (CAs), including public CAs compliant with the ACME protocol, enterprise PKI systems, and Kubernetes-native CAs. These connectors abstract the complexities of different CA implementations, providing a unified interface for certificate issuance, renewal, and revocation. Integration with Kubernetes admission controllers enables policy enforcement at deployment time, preventing non-compliant certificates from being introduced into the environment. 3.3. Policy Enforcement Mechanisms for TLS Configuration The policy enforcement layer forms a critical component of the TLS Protect architecture, implementing controls that ensure TLS configurations meet security and compliance requirements. The architecture defines a policy model that covers various aspects of certificate management, including allowed certificate authorities, key types and sizes, validity periods, and approved cipher suites. As Shamim, Bhuiyan, et al. [5] emphasize in the security commandments, policy Global Journal of Engineering and Technology Advances, 2025, 23(01), 250-257 253 enforcement is implemented at multiple levels: preventive controls through admission webhooks that validate new certificate requests; detective controls that continuously scan existing certificates for compliance violations; and corrective controls that automatically remediate non-compliant certificates. The policy engine translates high-level organizational requirements into specific technical constraints, which are then enforced through Kubernetes native mechanisms. This approach ensures that security policies are consistently applied across all services and workloads, regardless of where they are deployed. 3.4. Scalability Considerations for Enterprise Multi-Cluster Environments Enterprise Kubernetes deployments often span multiple clusters across different regions, clouds, and environments, presenting significant scalability challenges for certificate management. The TLS Protect architecture addresses these challenges through a hierarchical design that balances centralized control with distributed execution. The Venafi white paper [6] outlines how a central management plane provides policy definition and oversight, while distributed agents in each cluster handle local certificate operations. This architecture supports federation across clusters, allowing certificates and policies to be synchronized while respecting the boundaries between environments. The system implements efficient caching and state reconciliation mechanisms to minimize API server load and ensure responsiveness even in large-scale deployments. Horizontal scaling capabilities enable the system to grow with the organization's Kubernetes footprint, while providing consistent security guarantees across the entire infrastructure. The architecture also considers multi-tenancy requirements, allowing different teams or business units to manage their certificate policies within an overarching organizational framework. 4. Policy-Driven TLS Management Framework 4.1. Definition of Centralized Policy Control for Organizational TLS Requirements A centralized policy control framework for TLS management provides organizations with a unified approach to defining, implementing, and enforcing cryptographic requirements across Kubernetes environments. Building upon the policy enforcement theories developed by Helge Janicke, Antonio Cau, et al. [7], this framework establishes a clear separation between policy specification and implementation, enabling security teams to define high-level security objectives without specifying the technical details for each target environment. The centralized model supports hierarchical policy structures where organization-wide baseline requirements can be supplemented with environment-specific or application-specific policies. These policies define acceptable certificate authorities, required certificate attributes, key algorithms and strengths, validity periods, and renewal thresholds. The framework incorporates version control and approval workflows to ensure policy changes follow proper governance procedures, while providing audit trails for all policy modifications. This centralized approach eliminates fragmented security practices across teams and ensures consistent security posture regardless of deployment location. 4.2. Compliance Mapping to Industry Standards (NIST, CIS, PCI DSS) The policy framework includes comprehensive mapping to industry security standards and regulatory requirements to simplify compliance efforts. As outlined in the PCI Security Standards Council document [8], effective mappings between different frameworks enable organizations to implement controls that satisfy multiple compliance requirements simultaneously. The TLS management framework incorporates mappings to key standards including NIST Cybersecurity Framework, NIST SP 800-52 (Guidelines for TLS Implementations), Center for Internet Security (CIS) Benchmarks for Kubernetes, and Payment Card Industry Data Security Standard (PCI DSS) requirements for encryption. These mappings translate abstract compliance requirements into concrete policy controls that can be automatically enforced within Kubernetes environments. The framework maintains a current repository of compliance requirements and updates policy templates as standards evolve, ensuring organizations remain compliant with the latest security guidelines. By implementing these mapped policies, organizations can generate evidence of compliance through automated reporting mechanisms that demonstrate adherence to the required cryptographic standards. Global Journal of Engineering and Technology Advances, 2025, 23(01), 250-257 254 Table 2 Zero-Trust Security Requirements and Implementation Components [4, 8] Zero-Trust Requirement TLS Implementation Component Industry Standard Mapping Identity-based authentication Certificate-based service identity NIST SP 800-207 Continuous validation Certificate validity monitoring PCI DSS Req. 4.1 Least privilege access Fine-grained certificate scoping CIS Kubernetes Benchmark Encryption of all data in transit Enforced TLS for all communications NIST SP 800-52 No implicit trust Mutual TLS authentication NIST Zero Trust Architecture Centralized policy enforcement Automated certificate policy validation PCI DSS Req. 6.2 4.3. Policy Validation and Enforcement Mechanisms The framework implements multi-layered validation and enforcement mechanisms to ensure TLS policies are consistently applied throughout the certificate lifecycle. Following the enforcement derivation approach described by Janicke, Cau, et al. [7], policies are automatically translated into enforceable rules that operate at different control points within the Kubernetes environment. Pre-deployment validation occurs through integration with admission controllers that inspect certificate requests against policy requirements before allowing their creation. Runtime validation continuously monitors existing certificates for policy compliance, detecting issues such as deprecated cryptographic algorithms or approaching expiration dates. The enforcement layer leverages Kubernetes native mechanisms including custom resource definitions, admission webhooks, and operators to implement these controls without requiring changes to application code. Policy exceptions are managed through a formal process that requires documented justification, security review, and time-limited approvals, ensuring that deviations from standard policy are properly scrutinized and monitored. 4.4. Automated Remediation Workflows for Non-Compliant Certificates When certificate non-compliance is detected, the framework initiates automated remediation workflows to address the issue with minimal manual intervention. Drawing on policy enforcement principles established by Janicke, Cau, et al. [7], the system implements progressive remediation actions based on the severity and urgency of the compliance violation. For imminent certificate expirations, the system automatically triggers renewal processes through the appropriate certificate authority. When certificates use deprecated cryptographic algorithms, the framework initiates replacement workflows that generate new certificates with compliant algorithms while orchestrating the deployment of these replacements to minimize service disruption. For more complex non-compliance scenarios, the system creates prioritized remediation tasks assigned to the appropriate teams through integration with workflow management systems. Throughout the remediation process, the framework maintains detailed audit trails documenting the noncompliance issue, remediation actions taken, and verification of successful resolution, providing the necessary evidence for security audits and compliance reporting. 5. Implementation of Automated Certificate Lifecycle Management 5.1. Certificate Issuance and Provisioning Processes The implementation of automated certificate lifecycle management begins with streamlined issuance and provisioning processes that eliminate manual intervention while maintaining security controls. Drawing from service-oriented lifecycle management principles described by Rafia Inam, Athanasios Karapantelakis, et al. [9], the system implements a declarative approach where certificates are defined as Kubernetes resources with desired specifications. When a new certificate request is submitted, the system validates the request against organizational policies, initiates the issuance process with the appropriate certificate authority, and securely stores the resulting certificate and private key. The provisioning mechanism automatically distributes certificates to the appropriate services through Kubernetes secrets, ensuring proper access controls and encryption at rest. Integration with service discovery mechanisms enables applications to locate and utilize the correct certificates without hardcoded configurations. The implementation supports various issuance models including push-based provisioning for traditional services and pull-based retrieval for cloud-native applications, accommodating different architectural patterns while maintaining consistent security controls. Global Journal of Engineering and Technology Advances, 2025, 23(01), 250-257 255 Table 3 Certificate Lifecycle Management Components [9, 10] Component Primary Function Integration Points Certificate Orchestrator Manages certificate requests and deployment Kubernetes API, Service Mesh Policy Engine Enforces security and compliance requirements Admission Controllers, CRDs Certificate Authority Connector Interfaces with internal/external CAs ACME, Enterprise PKI and Venafi Certificate Monitor Tracks certificate health and expiration Prometheus, Alert Manager Rotation Manager Coordinates certificate renewal Deployment Controllers Revocation Handler Manages certificate invalidation CRLs, OCSP 5.2. Rotation Strategies for Minimizing Service Disruption Certificate rotation presents significant operational challenges, particularly in production environments where downtime must be minimized. The implementation incorporates sophisticated rotation strategies that follow the good practices for key management outlined by Marcelo Carlomagno Carlos, Ricardo Felipe Custódio, et al. [10]. The system implements proactive rotation, initiating certificate renewal well before expiration to provide adequate time for deployment and validation. A phased rotation approach maintains both old and new certificates during a transition period, allowing services to gradually migrate to new certificates without disruption. For stateful services that maintain long-lived connections, the implementation supports certificate chaining where intermediate certificates can be rotated independently from end-entity certificates. The rotation process includes pre-flight validation of new certificates, canary deployments to test certificate compatibility with a subset of traffic, and automated rollback capabilities if issues are detected. These strategies are implemented through Kubernetes operators that manage the complex orchestration required for zero-downtime certificate rotation across distributed services. 5.3. Revocation Mechanisms and Security Incident Response Effective certificate revocation is critical during security incidents involving compromised keys or certificates. The implementation provides comprehensive revocation capabilities aligned with the key management practices described by Carlos, Custódio, et al. [10]. When revocation is triggered, either manually during incident response or automatically by security monitoring systems, the framework immediately invalidates the compromised certificate through communication with the certificate authority, publishes the revocation information to certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP) responders, and removes the certificate from affected services. The system implements a graduated response based on the severity of the security incident, ranging from targeted certificate replacement to cluster-wide emergency revocation procedures. Integration with incident response platforms enables security teams to trigger certificate revocations as part of broader incident containment strategies. The implementation maintains detailed audit trails documenting the revocation reason, actions taken, and verification of successful revocation, providing critical forensic information for post-incident analysis. 5.4. Monitoring and Alerting for Certificate Health and Compliance Continuous monitoring is essential for maintaining certificate health and ensuring compliance with organizational policies. Building on the automated lifecycle management approach described by Inam, Karapantelakis, et al. [9], the implementation includes comprehensive monitoring capabilities that track certificate status, expiration dates, utilization patterns, and compliance with security policies. The monitoring system collects metrics on certificate lifetimes, cryptographic attributes, and usage patterns, enabling detection of anomalies that might indicate security issues. Proactive alerting notifies administrators of approaching expirations, compliance violations, or unusual certificate behaviors based on configurable thresholds. The monitoring implementation integrates with enterprise observability platforms through standard interfaces, allowing certificate health to be correlated with broader system and security metrics. Visualization dashboards provide security teams with real-time visibility into the certificate ecosystem, including certificate inventory, compliance status, and upcoming renewal activities. These monitoring capabilities enable organizations to maintain a proactive posture toward certificate management, addressing potential issues before they impact service availability or security. Global Journal of Engineering and Technology Advances, 2025, 23(01), 250-257 256 6. Evaluation of Zero-Trust Implementation with Mutual TLS 6.1. Methodology for Implementing mTLS Between Kubernetes Services The implementation of mutual TLS (mTLS) between Kubernetes services forms the foundation of a zero-trust security model, where all service-to-service communications require bidirectional authentication. Drawing from the extended TLS implementation methodologies described by Norazah Abd Aziz, Nur Izura Udzir, et al. [11], our approach establishes a comprehensive framework for deploying mTLS across Kubernetes environments. The methodology begins with a service identity model based on X.509 certificates, where each service receives a unique cryptographic identity tied to its Kubernetes service account. Certificate issuance is automated through integration with the service mesh control plane, which handles certificate distribution, rotation, and revocation without application modifications. The implementation includes network policies that enforce TLS for all in-cluster communications, preventing unencrypted traffic between services. This methodology addresses the complexities of mTLS in dynamic environments by implementing transparent proxies that handle TLS negotiation, allowing applications to remain unaware of the underlying security mechanisms while benefiting from the protection they provide. 6.2. Performance Impact Assessment of mTLS on Service Communication While mTLS significantly enhances security, its implementation introduces computational overhead that must be carefully evaluated in production environments. Following the performance analysis framework established by Aziz, Udzir, et al. [11], we conducted a systematic assessment of the impact of mTLS on service communication in Kubernetes clusters. The evaluation measured key performance indicators including connection establishment time, request latency, throughput, and CPU utilization across various workload patterns. The assessment compared baseline performance (no TLS), one-way TLS (server authentication only), and mutual TLS configurations to quantify the incremental impact of each security enhancement. Special attention was given to the performance implications during certificate rotation events, which introduce additional processing requirements. The evaluation also examined the scalability implications of mTLS in high-traffic environments, assessing how performance characteristics change as the number of services and request volume increases. These performance metrics inform optimization strategies that balance security requirements with operational performance. 6.3. Security Analysis of Protection Against MITM and Other Attack Vectors The security efficacy of the mTLS implementation was evaluated through a comprehensive threat modeling and analysis process. Building on the zero-trust security framework described by Lucas S. Cruz and Iguatemi E. Fonseca [12], the analysis assessed how the implementation addresses specific attack vectors relevant to Kubernetes environments. The evaluation focused on protection against man-in-the-middle (MITM) attacks, examining how certificate validation and pinning mechanisms prevent unauthorized interception of communications. The analysis also covered resistance to certificate spoofing, replay attacks, and downgrade attempts that might compromise secure communications. Additional security considerations included the protection of private keys within the Kubernetes environment, secure certificate storage, and the integrity of the certificate issuance process. The evaluation utilized both theoretical security analysis and practical penetration testing to identify potential vulnerabilities in the implementation, resulting in security enhancement recommendations that were incorporated into the final design. 6.4. Case Study of Zero-Trust Architecture Implementation in Production Environments To validate the practical applicability of the mTLS-based zero-trust approach, we conducted a detailed case study of its implementation in production Kubernetes environments. Drawing on implementation strategies outlined by Cruz and Fonseca [12] for industrial control systems, the case study examined the deployment process, operational challenges, and security outcomes across multiple organization types and industry sectors. The study documented the migration process from perimeter-based security models to zero-trust architecture, highlighting the phased approach that minimized disruption to existing services. Key findings included the organizational adaptations required for successful implementation, including changes to development workflows, security governance, and operational procedures. The case study also examined the integration challenges with legacy systems that lack native TLS support, documenting the proxy-based solutions that enabled consistent security policies across heterogeneous environments. The longitudinal analysis captured both immediate security improvements and long-term operational benefits, providing a comprehensive view of the zero-trust implementation journey. Global Journal of Engineering and Technology Advances, 2025, 23(01), 250-257 257 7. Conclusion This article has presented a comprehensive framework for automating TLS certificate lifecycle management in Kubernetes environments, addressing critical security challenges faced by organizations deploying cloud-native applications. The article established that policy-driven certificate management provides a robust foundation for implementing zero-trust security models through mutual TLS while ensuring compliance with industry standards. The architecture integrates seamlessly with Kubernetes native mechanisms, enabling organizations to enforce consistent security policies across multi-cluster environments without introducing operational complexity. The implementation demonstrates that automated certificate issuance, rotation, and revocation processes can eliminate manual intervention while maintaining strong security controls throughout the certificate lifecycle. Performance analysis confirms that the security benefits of mutual TLS can be achieved with acceptable operational overhead when proper optimization strategies are applied. The case studies validate the practical applicability of this approach across various organizational contexts, highlighting both the security improvements and operational efficiencies gained through automation. Future research should focus on extending the framework to address emerging cryptographic standards, enhancing integration with external identity management systems, and developing more sophisticated anomaly detection capabilities for certificate usage patterns. As organizations continue to adopt containerized architectures, automated certificate lifecycle management will remain a critical component of comprehensive Kubernetes security strategies. References [1] Chris Binnie and Rory McCune, "Kubernetes External Attacks," Cloud Native Security (Wiley Data and Cybersecurity), 2021. https://ieeexplore.ieee.org/abstract/document/9932401 [2] Kevin Walsh, "TLS with Trustworthy Certificate Authorities," 2016 IEEE Conference on Communications and Network Security (CNS), Feb. 2017. https://ieeexplore.ieee.org/document/7860543 [3] Michael Atighetchi, Nathaniel Soule, et al., "Safe Configuration of TLS Connections," 2013 IEEE Conference on Communications and Network Security (CNS), Dec. 2013. https://ieeexplore.ieee.org/document/6682755 [4] Naeem Firdous Syed, Syed W. Shah, et al., "Zero Trust Architecture (ZTA): A Comprehensive Survey," IEEE Access, June 2022. https://ieeexplore.ieee.org/stampPDF/getPDF.jsp?arnumber=9773102 [5] Md Shazibul Islam Shamim, Farzana Ahamed Bhuiyan, et al., "XI Commandments of Kubernetes Security: A Systemization of Knowledge Related to Kubernetes Security Practices," IEEE SecDev, Nov. 2020. https://secdev.ieee.org/wp-content/uploads/2020/11/s4-02-shamim.pdf [6] Venafi, "Machine identity management for TLS, mTLS and SPIFFE in cloud native and Kubernetes environments," Venafi White Paper, 2024. https://venafi.com/tls-protect-for-kubernetes/ [7] Helge Janicke, Antonio Cau, et al., "Deriving Enforcement Mechanisms from Policies," Eighth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'07), June 2007. https://ieeexplore.ieee.org/abstract/document/4262583 [8] PCI Security Standards Council, "Mapping PCI DSS v3.2.1 to the NIST Cybersecurity Framework v1.1," July 2019. https://listings.pcisecuritystandards.org/pdfs/Mapping-PCI-DSS-to-NIST-Framework.pdf [9] Rafia Inam, Athanasios Karapantelakis, et al., "Towards Automated Service-Oriented Lifecycle Management for 5G Networks," 2015 IEEE 20th Conference on Emerging Technologies & Factory Automation (ETFA), Oct. 2015. https://ieeexplore.ieee.org/document/7301660 [10] Marcelo Carlomagno Carlos, Ricardo Felipe Custódio, et al., "Good Practices for Long-Term Key Management in a Public Key Infrastructure," 2008 11th IEEE International Conference on Computational Science and Engineering - Workshops, Sept. 2008. https://ieeexplore.ieee.org/document/4625053 [11] Norazah Abd Aziz, Nur Izura Udzir, et al., "Performance Analysis for Extended TLS with Mutual Attestation for Platform Integrity Assurance," 2014 IEEE International Conference on Cyber Technology in Automation, Control, and Intelligent Systems, Oct. 2014. https://ieeexplore.ieee.org/document/6917428 [12] Lucas S. Cruz, Iguatemi E. Fonseca, "Industrial Control Systems in Environments with Zero Trust Architecture," IEEE Access, 15 December 2023. https://ieeexplore.ieee.org/document/10344788/authors#authors.