//// Purpose ------- Information about security. //// [id="security_{context}"] = Security ACS is deployed to provide vulnerability scanning, compliance checking, and runtime security for containerized workloads. == Identity and Access Management Access control is implemented through Helvetia's enterprise account system. The access management model follows the Principle of Least Privilege [POLP] with a maximum of two administrators per project. A dedicated RBAC tool is used to manage role-based access permissions across the platform. == Secrets Management Sealed Secrets are used to encrypt and manage secret resources on the OpenShift clusters. This implementation allows secret resources to be stored in version control while enforcing access controls and maintaining audit capabilities. == PKI Certificate management is handled through cert-manager with plans to implement an ACME provider. Currently, TLS certificates are issued through the internal Helvetia.io certificate authority. A migration project is underway to implement Helvetia.com certificates. Certificate lifecycle operations including issuance, renewal, and revocation are managed through automated processes. == Base Images The container image architecture uses Red Hat Universal Base Images [UBI] with additional components such as custom certificates, tracing agents, and specialized variants including Java, Quarkus, and JBoss tooling Base images are automatically rebuilt and pushed to Nexus on a monthly schedule to incorporate security updates and organizational requirements. == Compliance {cust} maintains a tailored profile of CIS benchmarks adapted to organizational requirements. Compliance monitoring and reporting of workloads is performed through Red Hat Advanced Cluster Security, which replaced the previously used OpenShift Compliance Operator, which focused more on Node compliance. == Conclusion {cust}’s security setup is centered on ACS for scanning, compliance, and runtime security. Access is controlled with sensible RBAC. Dashboards provide operational visibility. Expanding ACS policies, automating responses, and exploring mTLS for service communication via Red Hat Service Interconnect could further strengthen the security posture. While sealed secrets provide a secure way to store secrets in kubernetes, their limited interoperability with external tools—like github actions pipelines—creates friction in multi-tool workflows. An alternative like Hashicorp Vault could offer a more centralized and flexible approach, integrating smoothly across the dev and ops toolchain. However, vault introduces additional operational overhead, so its benefits would need to be weighed against the complexity it adds to the current setup. To address the interoperability gap with sealed secrets, we recommend implementing an automation script to decrypt secrets on-demand for github actions or other external tools. This script could securely access sealed secrets in openshift, decrypt them as needed in a controlled environment, and inject them directly into the pipeline runtime without exposing the actual secret values.