This post is from Edoardo Tenani, DevOps Engineer at Arduino.

In this blog, we’re going to answer: How does one store sensitive data in source code (in this case, Ansible playbooks) securely and in a way that the secrets can be easily shared with the rest of the team?

Ansible is an open source community project sponsored by Red Hat, it’s the simplest way to automate IT. Ansible is the only automation language that can be used across entire IT teams from systems and network administrators to developers and managers.

At Arduino, we started using Ansible around the beginning of 2018 and since then, most of our infrastructure has been provisioned via Ansible playbooks: from the frontend servers hosting our websites and applications (such as Create Web Editor), to the MQTT broker at the heart of Arduino IoT Cloud.

As soon as we started adopting it, we faced one of the most common security problems in software: How does one store sensitive data in source code (in this case, Ansible playbooks) securely and in a way that the secrets can be easily shared with the rest of the team?

Ansible configuration system comes to the rescue here with its built-in mechanism for handling secrets called Ansible Vault, but unfortunately it had some shortcomings for our use case.

The main disadvantage is that Vault is tied to Ansible system itself: In order to use it, you have to install the whole Ansible stack. We preferred a more self-contained solution, possibly compiled in a single binary to ease portability (i.e. inside Docker containers).

The second blocker is the “single passphrase” Ansible Vault relies on: a shared password to decrypt the entire vault. This solution is very handy and simple to use for personal projects or when the team is small, but as we are constantly growing as a company we preferred to rely on a more robust and scalable encryption strategy. Having the ability to encrypt different secrets with different keys, while being able to revoke access to specific users or machines at any time was crucial to us.

The first solution we identified has been Hashicorp Vault, a backend service purposely created for storing secrets and sensitive data with advanced encryption policies and access management capabilities. In our case, as the team was still growing, the operational cost of maintaining our Vault cluster was considered too high (deploying a High Available service that acts as a single point of failure for your operations is something we want to handle properly and with due care).

Around that same time, while reading industry’s best practices and looking for something that could help us managing secrets in source code, we came across mozilla/sops, a simple command line tool that allows strings and files to be encrypted using a combination of AWS KMS keys, GCP KMS keys or GPG keys.

Sops seemed to have all the requirements we were looking for to replace Ansible Vault:

• A single binary, thanks to the porting from Python to Golang that Mozilla recently did.
• Able to encrypt and decrypt both entire files and single values.
• Allow us to use identities coming from AWS KMS, identities that we already used for our web services and where our operations team had access credentials.
• A fallback to GPG keys to mitigate the AWS lock-in, allowing us to decrypt our secrets even in the case of AWS KMS disruption.
• The same low operational cost.

Sops’ adoption was a great success: The security team was happy and the implementation straightforward, with just one problem. When we tried to use Sops in Ansible configuration system, we immediately noticed what a pain it was to encrypt variables.

We tried to encrypt/decrypt single values using a helper script to properly pass them as extra variables to ansible-playbook. It almost worked, but developers and operations were not satisfied: It led to errors during development and deployments and overall felt clumsy and difficult.

Next we tried to encrypt/decrypt entire files. The helper script was still needed, but the overall complexity decreased. The main downside was that we needed to decrypt all the files prior to running ansible-playbook because Ansible system didn’t have any clue about what was going on: those were basically plain ansible var_files. It was an improvement, but still lacking the smooth developer experience we wanted.

As Ansible configuration system already supports encrypted vars and storing entire files in Ansible Vault, the obvious choice was to identify how to replicate the behaviour using Sops as the encryption/decryption engine.

Following an idea behind a feature request first opened upstream in the Ansible repository back in 2018 (Integration with Mozilla SOPS for encrypted vars), we developed a lookup plugin and a vars plugin that seamlessly integrate Ansible configuration system and Sops.

No more helper scripts needed

Just ensure Sops executable is installed, correct credentials are in place (ie. AWS credentials or GPG private key) and run ansible-playbook as you normally would.

We believe contributing to a tool we use and love is fundamental in following the Arduino philosophy of spreading the love for open source. 

Our sops plugins are currently under review in the mozilla/sops GitHub repository: Add sops lookup plugin and Add sops vars plugin. 

You can test it out right away by downloading the plugin files from the PRs and adding them in your local Ansible controller installation. You will then be able to use both plugins from your playbooks. Documentation is available, as for all Ansible plugins, in the code itself at the beginning of the file; search for DOCUMENTATION if you missed it.

If you can leave a comment or a GitHub reaction on the PR, that would be really helpful to expedite the review process.

What to do from now on?

If you’re a developer you can have a look at Sops’ issues list and contribute back to the project!

The Sops team is constantly adding new features (like a new command for publishing encrypted secrets in latest 3.4.0 release, or Azure Key Vault support) but surely there are interesting issues to tackle. For example, the Kubernetes Secret integration being discussed in issue 401 or the –verify command discussed in issue 437.

Made with <3 by the Arduino operations team!

Ansible® is a registered trademark of Red Hat, Inc. in the United States and other countries.

[Tijmen Schep] sends in his project, Candle Smart Home, which is an exhibit of 12 smart home devices which are designed around the concepts of ownership, open source, and privacy.

The central controller runs on a Raspberry Pi which is running Mozilla’s new smart home operating system. Each individual device is Arduino based, and when you click through on the site you get a well designed graphic explaining how to build each device. The devices them

It’s also fun to see how many people worked together on this project and added their own touch. Whether it’s a unique covering for the devices or a toggle switch that can toggle itself there’s quite a few personal touches.

As anyone who’s had the sneaking suspicion that Jeff Bezos was listening in to their conversations, we get the need for this. We also love how approachable it makes hacking your own hardware. What are your thoughts?

Admittedly, the headline is designed to get your dander up. You're in no immediate danger of a technologically-gifted thief plugging a couple of wires into your hotel door and making off with your sack of souvenirs from the Mall of America. But that's not to say it's impossible. Cody Brocious, who was recently brought on by Mozilla to work on Boot to Gecko, is giving a presentation at the annual Black Hat conference in Vegas where he demonstrates a method for cracking open keycard locks with a homemade $50 device. The hack only works on locks made by Onity at the moment, and real life testing with a reporter from Forbes only succeeded in opening one of three hotel doors. Still, with between four and five million Onity locks installed across the country (according to the company), that is a lot of vulnerable rooms. The attack is possible thanks to a DC jack on the underside of the lock that's used to reprogram the doors. This provides direct access to the lock's memory, which is also home to the numeric key required to release the latch -- a key that is protected by what Brocious described as "weak encryption." Ultimately the source code and design for the Arduino-based unlocker will be published online alongside a research paper explaining how these locks work and why they're inherently insecure. The hope is that manufacturers will take notice and improve the security of their wares before the world's ne'er-do-wells perfect Brocious' technique.

Filed under: Misc. Gadgets

Hacker finds flaw in hotel locks, can ruin your vacation with $50 DIY gadget originally appeared on Engadget on Tue, 24 Jul 2012 18:34:00 EST. Please see our terms for use of feeds.