consul-template VS rustls

The Hashicorp corporation has made a huge impact in providing valuable tools and platforms in the cloud ecosystem. The advantage of using the tools they provide, such as Terraform, Vault, and Packer, is that they all have the same language, Hashicorp Configuration Language (HCL). This means you can easily pick up any of these tools by learning HCL, which is similar to JSON. This approach can be useful when choosing tools to learn or use for a project.

Terraform is an open-source infrastructure as a code tool. It is designed by HashiCorp and written in Go Programming Language. Terraform is used to automate the creation of DevOps infrastructure and tasks. Terraform provisions and configures your DevOps infrastructure. It spins up new servers, creates load balancers, and node groups, and performs network configurations. Terraform is mostly applied to provision resources on cloud providers like AWS, Google Cloud, and Microsoft Azure. It can automate and provision infrastructure on any cloud platform. We will use Terraform to set up an Azure Kubernetes Service Cluster that has all the necessary cloud resources.

It can be time-consuming to create and manage the infrastructure that drives your software applications as they grow and become larger. Also, what about ongoing updates and releases of new features? Luckily, there is a solution to this problem in the form of a tool designed by Hashicorp called Terraform. This allows us to define our infrastructure in a central configuration file without having to create it on every provider platform we use.

HashiCorp Sentinel: Sentinel is a PAC tool developed by HashiCorp that can be used in tools such as Terraform, Vault, and Nomad. Sentinel supports writing rules in programming languages such as HCL to automate the enforcement of security and compliance policies.

Terraform is an infrastructure as code tool (IAC) created by HashiCorp that lets you automate cloud and on-prem resources. It uses configuration files written in HashiCorp Configuration Language (HCL) to declare resources (infrastructure objects) and define dependencies between them. To put it simply, this tool allows you to write a few configuration files and build a whole system’s architecture on the cloud by running a couple of commands. I found this to be a more efficient alternative to clicking through a console to create resources manually.

It was clear back in 2021 that Lob needed to consolidate how we run code and none of our current tools were up to the task; it wasn’t a matter of if Lob would upgrade to something new, but when. The Platform team kicked off a research project to find Lob’s next service platform. Forever ago (back in 2019) we investigated migrating to Kubernetes, a popular but notoriously difficult-to-manage tool for this sort of thing, but that project fizzled out for many reasons, forcing us to consider something else. We chose Nomad which offers a comparable feature set to Kubernetes in a much more streamlined package. Nomad is developed by HashiCorp, a leader in the DevOps space, and is used by companies like Pandora, Cloudflare, Internet Archive, and Roblox.

If however, you have an application service that needs support for 2+ ports, because you know, Kubernetes supports this, I would recommend avoiding Consul Connect, as it is not functional to meet minimum requirements for a service mesh. Perhaps someday, when Hashicorp prioritizes basic functionality and usability in future version, this product can be considered.

Looks a lot like Hashicorp (a technology company), maybe too similar, and not particularly evocative IMO.

AWS VPC is a simple example. This feature really shines when building reusable infrastructure-as-code for Network Firewall or even Network ACLs. Anything that simplifies something and reduces or eliminates any hacks required to reach a logical outcome is super valuable. Great work finally driving this one home HashiCorp.

The RustTLS project is currently setting up their own CI benchmarking workflow, so I think that you could find some inspiration there: https://github.com/rustls/rustls/issues/1385 and https://github.com/rustls/rustls/issues/1205.

I also studied this question on FFI several weeks ago in terms of "rewrite part of the system in Rust". Unexpected results could be semantic issues (e.g., different error handling methods) or security issues (FFI could be a soundness hole). I suggest going through the issues of libraries that have started rewriting work such as rust-openssl or rustls (This is the one trying to rewrite in whole rust rather than using FFI; however, you will not be able to find the mapping function in the C version and compare them). I hope this helps!

Now for rust implementation of tls. Certificates can be loaded in two ways. * Finds and loads certificates using OS specific tools3 * Uses a rust implementation of webpki4 for loading with certificates5

> Ring is mostly C/Assembly

Crypto needs to be written in Assembly to ensure that operations take a constant time, regardless of input. Writing it in a high level language like C or Rust opens you up to the compiler "optimising" routines and making them no longer constant time.

But you already knew this. And you also knew that the security audit (https://github.com/rustls/rustls/blob/master/audit/TLS-01-re...) of ring was favourable

> No issues were found with regards to the cryptographic engineering of rustls or its underlying ring library. A recommendation is provided in TLS-01-001 to optionally supplement the already solid cryptographic library with another cryptographic provider (EverCrypt) with an added benefit of formally verified cryptographic primitives. Overall, it is very clear that the developers of rustls have an extensive knowledge on how to correctly implement the TLS stack whilst avoiding the common pitfalls that surround the TLS ecosystem. This knowledge has translated reliably into an implementation of exceptional quality.

You said

> a standard library with feature flags and editions would make rust ridiculously much more productive

What's the difference between opting into a library with a feature flag and opting in with a line in Cargo.toml? Let's say you want to use the de-facto regex library. Would it really be ridiculously productive if you said you wanted the "regex" feature flag instead of the "regex" crate?

I do agree that the standard library does need a versioning story so they can remove long deprecated functions. Where it gets complicated is if a new method is reintroduced using the same name in a later edition.

I used the commands listed in the .sh file here: https://github.com/rustls/rustls/tree/main/test-ca to generate keys/certs for a server and a client (with IP.1 records for SANs). I have added the local root CA to the trust store of each VM.

This is great news, this was our single biggest annoyance with rustls. One of our cloud providers choses to issue their hosted postgres instances with TLS certificates with IP addresses. Unusual, but valid per the spec, so why not. Apparently a practise that's also popular in kubernetes settings, so I'm somewhat surprised it took 5 years to close the issue, but now I can finally recommend people to use rustls without mentioning any gotchas.

I believe it is more relevant than you think: servers running in containers, web assembler tasks running in browsers, embedded devices and kernels with total control of the system, all have the ability to do something more sensible than plain out SIGABRT or similar, and in many the case is not that the complete system is falling down. For example RustTLS is looking into allowing fallible allocators and as a pretty general-purpose library that seems like a nice feature. I do wish ulimit -v worked in a sensible manner with applications.