On June 13, 2023, the very first edition of HashiDays took place simultaneously in three cities: Paris, Munich, and London. Additionally, it was also possible to participate in the event online. I had the chance to attend the Paris edition.

In this article, we will review together the innovations presented during this day, particularly focusing on HCP (HashiCorp Cloud Platform), which is highlighted at every HashiConf/HashiDays.

HashiDays Paris 2023

HashiCorp Vault

A major innovation regarding Vault is HCP Vault Secrets, which is currently in public beta.

In essence, this new feature allows:

  • Simple and centralized storage of secrets: The goal is to view the solution as a “keyring SaaS”.
  • Centralizing secrets between HCP Vault Secrets and cloud providers/machines: Currently, the solution only supportsAWS Secret Manager, but support for others is coming soon.
  • Accessibility via an API or CLI: With a focus on providing “Developer Flexibility,” an API is available to retrieve a secret using Curl, Terraform (via the Vault provider), a dedicated CLI for Vault Secrets (called vlt), or an SDK. In terms of SDK, the community wasted no time, as a GO SDK has already been developed.

HCP Vault Secrets

To top it all off, HCP Vault Secrets is free during the public beta. It’s a great opportunity to test the product for yourself.

Another innovation for Kubernetes users, which was released a few months ago but highlighted during HashiDays as a GA (Global Availability) announcement, is the Vault Secrets Operatorr. This integration allows seamless synchronization with all Vault secret types. For those interested in understanding the differences and comparing it with other methods, you can refer to HashiCorp’s blog post on Kubernetes integrations with Vault.

Vault Secrets Operator

For more information:

HashiCorp Boundary

HashiCorp Boundary 0.13 has been released! Among the new features, some are accessible through the Open Source version, while others are available via HCP.

For the Open Source version, we have:

  • LDAP authentication method (beta)
  • OIDC authentication improvements: The CLI can display the authentication URL so that it can be continued on another device (especially for devices without a web browser).
  • Shared KMS workers: The use of one or multiple KMS to register downstreams across multiple networks.
  • Static ports for targets
  • Dynamic host catalog external name

Boundary Enterprise

On the Enterprise side:

  • Boundary Enterprise version: The ability to deploy an Enterprise version of HashiCorp Boundary in a self-hosted environment. It includes most of the features of HCP Boundary but not all (e.g., automated updates, streaming of audit logs, etc.). You can see the difference between HCP Boundary and the enterprise version on the pricing page.
  • SSH session recording: Records all commands in a session and stores the recording as a GIF. Currently, this feature only supports SSH and stores the recording in an AWS S3 bucket. It’s worth noting that the Boundary worker sends the file (along with the integrity file) to the S3 bucket ONLY when the session ends. One improvement to note from my testing is that access to the AWS S3 bucket is currently done via static Access Key & Secret Key. We hope to see integration soon with AWS Role or other more dynamic access methods. In terms of pricing, this new feature introduces the HCP Plus offering at $0.90 per session (compared to the HCP Standard offering at $0.50).
  • HCP Boundary maintenance window: You can now choose a maintenance window to update your Boundary (for patching or upgrading to a major version).

Boundary Session Recording Boundary Session Recording - Demo

For more information:

HashiCorp Consul

On the Consul side, the new features are divided into two parts, with HCP Consul Management Plane and Consul v1.16 in BETA.

For HCP Consul Management Plane, we have two featured components:

  • Cloud-based observability (beta): Focused on three key elements: Telemetry extraction, Metrics storage & Visualizations. It provides a global view across multiple environments, services, and overall health status.
  • Cluster peering (GA): Simplifies cross-cluster connectivity through the HCP interface, supporting both HCP and self-managed clusters.

On the other hand, with Consul v1.16 still in BETA, we have:

  • Sameness groups (Consul Enterprise): Enables failover between a service distributed across multiple clusters/partitions.
  • Enhanced control plane protection (Consul Enterprise): Adds rate limiting based on IP address.
  • FIPS 140-2 compliant (Consul Enterprise): Built to comply with FIPS 140-2 Level 1 standards.
  • JWT auth for service-to-service traffic: Consul service intentions can now authorize JWT (Json Web Token) claims.
  • Transparent proxy for failover and virtual services: Introduces a transparent proxy mode.
  • Permissive mTLS: When enabling mTLS (Mutual TLS), Consul previously required ALL communications to be secured with mTLS. With Permissive mTLS, the transition to mTLS can be made without requiring all communications to use mTLS.
  • Simplified API Gateway installation for Consul on Kubernetes
  • External AuthZ Envoy extension: Allows the use of an external Envoy to filter authorizations on TCP and HTTP listeners.
  • Property override Envoy extension
  • Wasm Envoy extension: Enables the use of the WebAssembly (Wasm) extension for TCP and HTTP listeners via Envoy.
  • Catalog sync support for health checks and ingress

Consul 1.16 recap

For more information:

HashiCorp Terraform

To conclude the wave of new features, we end with HashiCorp Terraform. In a similar fashion to Consul, the new features are divided into two parts: Terraform Cloud and Terraform v1.5.

Terraform recap

Let’s start with the exciting new features in Terraform v1.5:

  • Config-driven import: THE long-awaited feature of importing resources with automatic code generation by Terraform has arrived. The process consists of two steps:
    1. Create the target resource and an import {} block:
    import {
  id = “i-abcd1234”
  to = aws_instance.example
}

resource "aws_instance" "example" {
  name = "test"
}
    Here, id represents the ID of the existing resource, and to indicates the Terraform resource to be generated. 2. You can then run your plan and/or apply to view and/or generate the resource in Terraform with its attributes. Unlike the terraform import command, the use of the block is idempotent, making it easy to remove the configuration if desired.

    Warning

    Caution with imports: Imports bring in all attributes, and some may conflict.

  • Enhanced validation with checks: Another equally important feature is the check {} blocks. checks enable functional tests as a non-blocking for Terraform (checks are run at the very end), whereas post conditions are more focused on unit tests and blocking Terraform deployment. check and post condition are complementary. Here’s an example from the HashiCorp blog article:
check "health_check" {
  data "http" "example" {
    url = "https://${aws_lb.example.dns_name}"
  }
 
  assert {
    condition     = data.http.example.status_code == 200
    error_message = "${data.http.example.url} returned an unhealthy status code"
  }
}

On the other hand, with Terraform Cloud, we have:

  • Explorer for workspace visibility (beta): A consolidated view that includes information about providers, modules, Terraform versions used by workspaces, detected drift, and more.
  • Ephemeral workspaces (coming soon): Allows setting a Time To Live (TTL) for a workspace. At the end of the TTL, the workspace is destroyed along with all its resources using terraform destroy (perfect for frequently forgotten dev environments).
  • Config-driven import (GA): Utilizing the Terraform v1.5 feature of import blocks. Terraform Cloud allows visualizing the import resources and downloading the configuration of those import.
  • Continuous validation with Terraform checks (GA): As the same logic like the Config-driven import feature of Terraform Cloud, the platform utilizes this new feature to notify users if a check fails.

For more information:

Nomad, Packer et Vagrant ?

There were no specific announcements for these products during the HashiDays event. The event primarily focused on products that have enterprise versions and/or are available through HashiCorp Cloud Platform (HCP).

To further enhance your journey in the HashiCorp world, I invite you to learn more about other updates through the following resources:

HashiDays Paris 2023 in-person, the feedback !

Be at the in-person event in Paris worth for 2024?

Yes. The HashiDays event successfully highlighted the in-person aspect, especially with a morning session (from 9:30 am to 10:30 am) and a very successful networking after-work event in my opinion. As a fun anecdote, I had the opportunity to meet former classmates from my school at each HashiCorp event (every year) whom I haven’t seen in years. It’s also an opportunity to meet other HashiCorp Ambassadors and HashiCorp Core Contributors.

HashiCorp Ambassaodr

What about the talks?

The talks were organized into four phases:

  1. Keynote (morning)
  2. Deep Dive sessions on the new features (morning/noon)
  3. Experience-sharing talks (early afternoon)
  4. Learning sessions with demonstrations/labs to reproduce (late afternoon)

Overall, the program was good with regular breaks. However, it lacked a second track to choose topics based on individual preferences, and more dedicated time in small groups for the Learning sessions for those who wanted to follow along the demonstration (as the pace was very fast, and it was difficult to ask questions during the demonstration).

Final thoughts?

For those who are new to HashiCorp products, considering the Pro or Enterprise offerings, and looking to discuss with experts on the subject, HashiDays is the ideal place to be. However, for those who already have advanced knowledge of HashiCorp products and mainly focus on open-source offerings, you may be generally less satisfied, except for the networking time and a few talks.

To wrap up, here are a few bonuses: