Robert Masterson | Senior Partner Marketing Manager
The shift toward cloud-native applications is changing the building blocks of IT. Development and maintenance of infrastructure and applications in-house just isn’t an option anymore in many cases. Cloud-native application development and the use of containers and orchestration frameworks like Kubernetes offer undeniable advantages in performance, portability and scale.
However, it’s obvious to security teams that the possible attack surface has grown as a result. On-demand, large-scale deployment of IT resources across a mix of public and private clouds means that security vulnerabilities or exploits can often go undetected. Knowing who and what can be trusted is a constant struggle, as malicious code, untrusted connections, and misconfiguration all lead to one thing – more risk.
Several mechanisms help application and security teams to mitigate these risks, but identity is at the core. Identifying all of the “things” (e.g. workloads, services, code) across every cloud or network, verifying integrity, and encrypting connections end-to-end is half the battle. Two critical functions that make this possible are signature enforcement and trust authentication, both of which can be accomplished through the use of X.509 certificates.
SIGN EVERYTHING
Developers should always digitally sign code to protect end users from downloading and installing compromised code. Code signing ensures that the application cannot be modified by an unauthorized user, and provides high assurance that only authentic code developed and vetted by the vendor will be executed. Once the software is packaged into containers for deployment to the cloud, the containers can be signed as well. For instance, Docker supports container signing to enable verification of container integrity and publisher.
We recommend both levels of signing. If the application is signed, but the container is not, then a malicious user could potentially run other malicious code on the container in addition to the legitimate code. Enforcing signatures is no doubt necessary, but even more important is the protection of certificates – and their associated private key – used for signing. If these keys are compromised, attackers can use them to sign malicious code, making it appear authentic and trusted the same as your software.
Keyfactor Code Assure is purpose-built to solve these problems. The platform provides developers with programmatic access to certificates to sign code, while the security team keeps a tight audit trail of all signing activities and ensures that the private keys remain secure in an integrated Thales HSM. Storing the private keys in a FIPS 140-2 Level 3 complaint Thales HSM – either on-premises or cloud-based – ensures that, even if someone has access to the location, they cannot extract or copy the certificate.
Notably, signing can be done remotely, eliminating the need to distribute sensitive keys to multiple teams or locations. The Keyfactor Cryptographic Storage Provider (CSP) and APIs allow integration into nearly any CI/CD pipeline or build process, whether you’re using Microsoft SignTool for Windows executables, jarsigner for Java authentication, or a more complex tool like Jenkins.
ESTABLISH SECURE IDENTITIES FOR EVERYTHING
A best practice is to ensure that every connection to, from, or within a container or cluster uses SSL/TLS to enable mutual authentication and end-to-end encryption. This prevents unauthorized adversaries from making a connection that could compromise the security of a container or entire cluster. It’s also important to monitor and audit SSL/TLS certificates that are issued and active. Unknown, rogue or non-complaint certificates can result in an unexpected outage, or worse, misuse that allows unintended access to restricted systems.
For instance, Kubernetes can generate and issue certificates on its own, but most find that it doesn’t provide the visibility they need to ensure that certificates haven’t been issued inappropriately. However, Kubernetes also supports the ACME protocol, which can be used to obtain certificates from other sources, such as Let’s Encrypt. This protocol integrates with the Keyfactor ACME Server and is included as part of Keyfactor Command (our PKI-as-a-Service and certificate automation platform) to obtain certificates from any enterprise-supported PKI, whether public or private, that is configured in the Keyfactor platform. This enables secure, automatic issuance of a unique, trusted identity certificate for every container at deployment. This is done with robust role-based access control to different certificate templates or products, along with extensive workflow, auditing, and alerting capabilities, to provide the peace of mind that no certificates are being issued or used when they should not be.
Certificates issued for containers should be short-lived to limit the number of unexpired certificates active at any given time, which can often exceed thousands. This will help reduce the risk of compromise and lessen the impact if a certificate were stolen, since it will expire soon anyway. However, the certificate that cannot be short-lived is also the most important – the certificate of the Certificate Authority (CA) itself.
As with code signing, securing the CAs that issue the certificates is critical. If a CA is compromised, attackers can issue their own identities that will be trusted by default across an organization’s ecosystem, and this can be extremely costly to remediate, as it effectively invalidates every identity issued by that CA. The Keyfactor Command platform, integrated with Thales HSMs to secure CA certificates and keys, ensures robust protection and complete visibility, policy enforcement, and automation for all certificates.
Keyfactor and Thales offer integrated solutions designed to provide organizations with the tools they need to seamlessly automate secure operation of containerized and multi-cloud environments with minimal effort.
For more information, please check out our recent webinar on “Unlocking DevOps Security with PKI Automation”.