HashiCorp’s Zero Trust Model for Securing Human and Machine Communications
By Loren Blinde
June 18, 2024
From IC Insider HashiCorp
By Gerald Dykeman, Daniel Fedick, Tim Silk
As part of NIST’s Zero Trust Model, there is often a strong focus and solution set for securing Person Entity (PE) to Non-Person Entity (NPE) access (also referred to as human-to-machine access). Zero-Trust (ZT) human access often happens through privileged access management(PAM) solutions, virtual private networks (VPNs), or identity-aware proxy (IAP) access. However, a similarly strong emphasis should be placed on securing machine-to-machine access and communications as part of the Zero Trust Model; the underlying assumption is to trust nothing and authenticate and authorize everything.
In this article, we will dive into two HashiCorp technologies known as Vault and Consul and how they, in tandem, provide a secure service mesh solution for communications between applications and services.
New greenfield environments deploying microservice applications are becoming the accepted standard within the Department of Defense. Orchestration platforms like Rancher and OpenShift Kubernetes have become quite popular and are frequently used with Consul and Vault to secure identity, credential access, and microservice security. These greenfield environments scale well and allow for faster development.
But what about the “brownfield” environments that might not be able to be quickly migrated? The DoD aims to implement a zero-trust architecture that seamlessly integrates existing platforms with new ones. HashiCorp’s solution provides an agnostic, unified workflow for identity brokering and application credential lifecycle management, ensuring secure access for humans, machines, and services across diverse platforms, cloud service providers, and operating systems.
Centralized Secrets Management
Vault is HashiCorp’s identity broker and credential access and management solution. Vault tightly controls access to sensitive data such as passwords, certificates, keys, and tokens, and realistically any data that needs to be protected. Identity is the center of Vault’s security model. Humans and machines must authenticate themselves at every interaction. Vault accomplishes this with a “bring your own authentication” model using “Authentication Methods.” Methods like AD, Keycloak, OIDC, SAML, LDAP, etc., are common authentication methods. This allows Vault to act as an identity broker between disparate organizations, no matter the authentication method used.
Once authenticated, and authorized based on policy, access to “Secret Engines” provides credentials like encryption keys, SSH keys, JWT tokens, databases, PKI, TOTP, etc. These credentials are dynamically generated with a Time-To-Live (TTL) provided to the user.
Figure 1: Authenticate and authorize every access request
The three key pillars of HashiCorp’s Vault are shown in Figure 1 above.
- Identity-based security: Any human or machine entity must prove their identity via trusted identity providers whereby Vault becomes the identity broker. This allows for a centralized authentication and authorization method to access secrets.
- Secrets management: The core pillar of HashiCorp’s Vault, secrets are now centrally stored, protected, and managed anywhere on any platform.
- Credential Lifecycle Management: A fundamental principle of Vault, as it relates to the Zero Trust Model, is that a breach or a malicious actor is assumed. By utilizing dynamic, short-lived, just-in-time secrets, Vault significantly mitigates against a compromise, creating a constantly moving target, preventing lateral movement, and ensuring tighter data security. Additionally, if data is breached, it is always encrypted, rendering it useless to the attacker.
Services Networking Platform
Consul, HashiCorp’s service networking platform, empowers organizations to effortlessly discover and securely connect applications or services across any cloud or platform. Like Vault, Consul shines in both static and dynamic environments, making it a perfect fit for navigating the complexities of multi-cloud setups and microservices. By automating service discovery and secure communication between services, Consul enables a shift from the manual management of network rules to a centralized, identity-based security model that enforces a zero-trust network.
Figure 2: Consul is a services networking platform
There are four core functions for HashiCorp’s Consul
- Service discovery for connectivity. To enable service discovery, Consul provides a service registry of all running nodes and services, along with their current health status. This allows for a centralized source of truth for all running applications and services across any network or platform.
- Secured Services via certificate-based service identity. Consul provides each service with an identity encoded as a TLS certificate. This includes a number of benefits:
- Establishes service identity
- Encryption of all traffic
- Standard TLS certificate with Secure Production Identity Framework For Everyone (SPIFFE) compatibility
- A built-in certificate authority (CA) or integrated with 3rd party CA, such as DoD PKI, Digicert, Entrust. etc., or even a Private Root CA like Vault (PKI Workshop is available upon request).
- Network infrastructure automation via Terraform. Consul can integrate with Terraform to provide a feature known as Consul-Terraform Sync (CTS) sync to dynamically update network devices. CTS automatically re-configures network devices based on infrastructure changes tracked by Consul. CTS is triggered by Consul, based on changes to service identities, not IP addresses. This alleviates the need for manual ticketing systems or workflows that can take days or weeks to execute.
- Secure service access for consistent traffic management. Consul provides a built-in API Gateway to control L7 access into the service mesh without installing a separate tool or product. The API Gateway routes traffic to the appropriate endpoint and improves security by reducing the access points into the service mesh. Administrators and developers have a single consistent platform to manage both East-West and North-South traffic.
- Mesh to Mesh Connectivity – Consul also enables peer clustering, allowing multiple Consul service mesh regions, data centers, or cluster connectivity ensuring the enforcement of identity, authentication, and authorization at every application interaction. This can help in a cross-domain or a mission partner environment.
Vault as Consul’s Service Mesh Certificate Authority
Consul is delivered with a built-in Certificate Authority (CA) system which can be used as the CA provider for service mesh certificate management. A CA provider manages root and intermediate certificates and performs certificate signing operations. The Consul leader orchestrates CA provider operations as necessary, such as when a service needs a new certificate or during CA rotation events. This CA provider abstraction allows different systems beyond the built-in CA to be utilized for storing and signing certificates. Consul supports Vault as a system provider whereby the root certificate and private key material are stored in Vault.
Figure 3
In the above figure, Vault is the Intermediate CA signed by the Trusted Root. Consul then becomes the signing CA where the service mesh now provides each service with its identity-encoded TLS certificate. This enables Consul service mesh services to establish and accept connections with other services.
The client service verifies the destination service certificate against the public CA bundle. The destination service also verifies the client certificate against the public CA bundle. After verifying the certificate, the next step depends upon the configured application protocol of the destination service. TCP (L4) services must authorize incoming connections against the configured set of Consul intentions(*), whereas HTTP (L7) services must authorize incoming requests against those same intentions. If the intention check responds successfully, the connection/request is established. Otherwise the connection/request is rejected.
As seen in Figure 3, the communication between SVC A and SVC B was first mutually authenticated via the sidecar proxy certificates. Once authenticated, service intentions were checked to verify that SVC A and SVC B were authorized to communicate. Once authorized, communication was established. The same can be seen between SVC A and SVC C. However, SVC C and SVC D were not able to establish communications due to a denied intention.
Additionally, the tight integration between HashiCorp Vault and Consul ensures that the intermediate CA and the service mesh CA are separate entities with unique authentication and authorization requirements. This separation of duties ensures that a compromise of one system doesn’t mean the compromise of another – an important component of the Zero Trust Model.
*Intentions control traffic communication between services at the network layer, also called L4 traffic, or the application layer, also called L7 traffic. The protocol used by the destination service to send and receive traffic determines the type of authorization the intention can enforce.
Conclusion
HashiCorp offers a wide range of solutions to equip organizations with a unified platform to efficiently and effectively operate and automate on any infrastructure whether on-premises, multi-cloud, or hybrid cloud. In this article, we focused on HashiCorp’s Vault and Consul. Vault is the identity-based centralized secrets management solution for both humans and machines. Consul is the services networking platform to enable secure communications between services based on identity. The tight integration between Vault and Consul enhances the security posture for organizations by separating the trusted certificate authority from the service mesh while dynamically rotating certificates on a short TTL to minimize the threat window and keep a moving target.
Additional Information
- If you want to learn more, you can check out the AFCEA Signal Magazine webinar with HashiCorp and Rancher Federal.
Contact us
If you’re interested in getting hands-on with our products and would like a demo, or an instructor-led workshop given by one of our engineers, feel free to contact us!
Gerald Dykeman (DoD HashiCorp Solutions Engineer)
Dan Fedick (DoD HashiCorp Solutions Engineer)
Tim Silk (Federal Director of Solutions Engineering)
About IC Insiders
IC Insiders is a special sponsored feature that provides deep-dive analysis, interviews with IC leaders, perspective from industry experts, and more. Learn how your company can become an IC Insider.
