Enterprise Compliance and Governance with HashiCorp Consul 1.8

The release of HashiCorp Consul 1.8 introduces two new enterprise features: Single Sign-On (SSO) and Audit Logging. While these features may not affect the basic functionality of Consul directly, they are often critical for enterprises with regulatory compliance requirements or strict organizational policies. Some core considerations for enterprises that are adopting new tools include:

• How to control what actions can take place in a given environment
• How to control who can access those environments
• How to inspect actions and access them after the fact

In this blog, we’ll walk through these considerations and talk about two new features that, combined with the existing enterprise feature of namespaces, enable these types of enterprises to run Consul both at scale and in a compliant manner.

»Namespaces

Before diving into the new features, it’s important to review namespaces. Namespaces can enhance audit logging and single sign-on by minimizing the surface area that these other features need to monitor and govern over. While these other features are great on their own, namespaces provide a more granular way of implementing them, which can be greatly beneficial for organizations with a large Consul deployment.

Namespaces were introduced in Consul 1.7. The capability provides a way to logically segment services at the group level, enable broad policies, and enable self-service by providing global administrators the ability to delegate management of these services to other operators. Services can be grouped in a namespace regardless of whether they reside in different datacenters, regions, or clouds, as long as they are reachable for Consul.

Namespaces leverage Consul’s Access Control List (ACL) system to enforce policies and control access to services within the namespace. For example, an operator could choose to implement a read only ACL policy for a subset of specific users that need to use Consul to discover certain services, but are not authorized to register new services or alter existing ones.

One path for enforcing a rule like this is to apply the policy at the token level for anyone interacting with services in a specific datacenter. The challenge with doing this is that it creates additional overhead for the operator when new services are registered or deregistered. The operator would have to update the ACL policy for the timeframe that they need write access and then remember to change the policy back to read when they are finished. Also, what if that operator doesn’t want that set of users to see all available services? Unique names or tags could be used to differentiate services. However, this introduces additional operational overhead and increased risk of misconfigurations.

A different approach would be to assign that subset of services a specific role and assign the users to their own namespace. Doing this enforces the policy within the namespace and is applicable to any services, new or existing. Namespaces allow operations teams the ability to control access to these environments, provide a system in place for inspection, and allow teams to remove the requirement to coordinate resource names between other users of the system.

»Single Sign-On

The scenario that we illustrated above requires a crucial consideration for managing access to services: the user. In order to gain access to the namespace, Consul only requires that a user provide a valid ACL token, regardless of who submits it. In an ideal world, the operator would have a system for managing the life-cycle of ACL tokens, including rotating them at periodic intervals, but in reality this is burdensome and not a scalable solution. Namespaces can contain multiple sets of services with different ACL policies. However, keeping track of the token usage across multiple policies and roles can get cumbersome quickly.

A better approach would be to leverage an existing trusted identity source for verifying that a user has access to Consul prior to them being able to interact with an agent. This is what single sign-on helps solve.

With Consul Enterprise 1.8, Consul admins can require users to authenticate through an OpenID Connect (OIDC) provider, like Okta, Ping, or Auth0, before that can make any changes inside of Consul. Similar to other SSO workflows, when a user attempts to login to Consul, either by the CLI or UI, they will be directed to a browser-based IdP to authenticate their credentials. Upon authentication, the IdP will inform Consul of the valid permissions and the users can proceed as normal.

Pairing SSO with namespaces is a way to ensure that only specific users have access and their permissions are mapped accordingly. In the circumstance listed above, even if an ACL token has been compromised, Consul 1.8 allows users to configure a Time to Live (TTL) for tokens created by SSO authentication. Additionally, if that attacker were somehow able to pass authentication, they can only go as far as the user they are impersonating is permissioned to go, which could be into a namespace limited by policies like we listed above.

»Audit Logs

Having covered adding restrictions to prevent unwanted access or actions, the last piece we’ll cover in this blog is inspection. Consul Enterprise 1.8 adds audit logging to Consul making it ideal for larger enterprises that require keeping records of network actions either for regulatory or organizational compliance reasons. Audit logging simply captures the events that Consul processes and compiles them into a JSON format for easy export. Using these logs, auditing teams can inspect event data to learn which credentials have been used, what actions have taken place, and the dates associated with all of these transactions. This provides greater oversight and accountability for security teams that might be concerned with automating service networking tasks.

»Conclusion

Consul Enterprise 1.8’s features offer a better way for enterprises to move to a newer, service-based networking approach while staying compliant with organizational policies. These features leverage familiar workflows that are used in other aspects of the business, like HashiCorp Vault and Terraform. As in the case with those products, we added these features to Consul to help enterprises tackle the challenges of collaboration and governance that arise as organizations start to scale their application deployments across multiple environments. To learn more about these features or Consul, please visit our product page or request a demo.