The last mile of sensitive data

“The last mile” is a term used in supply chain management and transportation planning to describe the last leg of a journey comprising the movement of people and goods from a transportation hub to a final destination. We can find examples of the last mile in telephony where the last mile is a physical last mile of copper wire, and in eCommerce, where the last mile is the fulfilment process, where your goods will be shipped and handled and arriving at your doorstep.

Most modern software projects today, whether on a traditional cloud stack or a cloud native stack, contain a set of technologies that offer a developer-productivity promise. With this promise of increased productivity however, comes an increase in complexity. Take for example a project on your typical Kubernetes stack. In addition to Kubernetes itself, it may also contain:

• Kubernetes related tools (Istio, Helm)
• Docker
• Docker tools
• Development and testing tools (e.g. K3s, Minikube)
• Cloud SaaS vendors (like AWS, GCE, Mailgun, Mixpanel and many others)

The crucial part of gluing everything together — since these all eventually have to integrate together — is authentication, authorization and secrets and access detail.

These challenges often lead to painful disarray for the developers who need to build for themselves a coherent, unified development experience. It is almost guaranteed to result in shortcuts, scripts and makeshift tools to enable access and integration: How do you pull a token from mailgun, inject it into your Kube cluster, but also have the sandbox token in your minikube cluster, and perform an integration test for all of those combined? How do you move from minikube to k3s and take all of those specially-crafted scripts that pull secrets from multiple secret stores?

The difficulties with handling secrets and access details can lead to three major issues for developers:

1. Leaks and breaches
2. Secret sprawl
3. Unproductiveness

Let’s take a closer look at each of these.

SEE ALSO: MicroK8s: Big Things Come in Small Packages

Developers, developers, developers.

Successful software projects have healthy production workloads, are monitored, have alerts in place, as well as fire-drills and processes that are well-known and well-rehearsed. When something fails, you probably know about it sooner rather than later. In terms of data safety, sensitive data can travel back and forth freely and securely within our production clusters.

The last mile of handling sensitive data and secrets in software, and more specifically in software development processes and our individual development habits, is often uncharted territory and a developer workstation can become chaotic.

Leaks and breaches: Products of chaos

The chaos that’s created isn’t great, to say the least. It leads to forgotten keys, misplaced tokens, exposure and leak of secrets and sensitive files. Above all, it causes individuals to mistakenly override organizational security controls. You can have great security on your production workloads, but chaos in the last mile due to the habits of day to day software development.

As developers, we use solutions and practices to deal with this last-mile problem such as 12-factor apps, .env, various next-gen developer-friendly software vaults, such as Hashicorp Vault and cloud native developer-friendly key value stores like Consul and Etcd (all of which open source!). Yet it’s often hard to visualize what “productive” looks like with all these, and to create a streamlined, razor-sharp and secure workflow to support developer productivity and also security.

Secret Sprawl: The exponentially growing problem

Secret sprawl is a term for the bad practice that happens when your organization stores sensitive information, such as secrets, keys, and other types of sensitive data, in many different places. In order to make life easy, and lacking any proper solution, developers may place such secrets hardcoded in code itself, in configuration files, in IaC (infrastructure as code) repos, in their private workstation setup (shell environment, zsh, IDEs) and more.

When secret sprawl initially happens — as a function of organization growth — the problem grows exponentially. For a healthy and growing organization, codebases grow, people duplicate, share, or release code internally, which gets shared once again, and the network effect takes care of growing secret sprawl massively inside the organization.

Often secret sprawl happens without individuals realizing it, because it’s naturally hard to see the bigger picture, and existing solutions are not doing a good enough job (Full disclosure: that’s why we’re building Spectral, which solves precisely this problem).

Unproductiveness: Microservice and cloud-native fatigue

In an organization with a micro-services or could-native landscape, you often need to bring up a couple Go services, as well as a Kafka and a Node service from a few different teams, just to get going with development on a project. It’s reasonable to assume that you’re not aware of how these should be set up in terms of their data, context, and secrets. Furthermore, it’s quite obvious that out of security concerns, the services originating teams wouldn’t want to share their secrets.

Vaults and key stores can be used to provide different teams safe and sandboxed secrets. However, the details of how to get and set these up are baked into READMEs, custom scripts and word-of-mouth, which is far from ideal.

Teller: Never leave your command line for secrets

Teller removes these risks completely as it acts as the “last mile shipping hub” of secrets on your workstation. You simply start your development environment with teller run and all of the necessary secrets and sensitive data will be provided to the various services, based on the teller.yml configuration file. Not to worry — the teller.yml file contains no secrets — but instead contains the metadata that is required to fetch these secrets. The secrets are always stored in their best and most secure place to be – the organizational vault or other secure key stores (we support almost all keystores that exist!). Teller makes sure that they are never written to any file or persisted to any storage device.

Teller encourages developer environment hygiene, as it will never give a child process secrets that the owning shell process may contain. Every process is run with a context which is on a need-to-know basis. This has a nice side effect that nullifies the vulnerability where hackers build processes that steal environment variables, which often include tokens and secrets that the developer is using in their development environment.

Teller also solves productivity, by taking all of the domain knowledge about secrets and packing it into one simple teller.yml file that each team creates. From there on, you just teller run the required services and all of the necessary secrets are auto-magically fetched and provided.

This can help developers and teams demo their product, tame the complexity and context switch more effectively, without the fatigue associated with remembering, instructing, and checklisting these actions.

SEE ALSO: How Java’s security methods have changed in 20 years

Summary

Teller is an open source and free tool that helps developers create a clean and hygienic development environment, helps them follow infosec policies and facilitates first-class use of existing vaults, key stores and other sensitive data storage facilities.

As a side effect, by merely using Teller, we can block a number of possible attacks on our processes and personal workstations.

You can mix and match any kind of vault, key store, or API you can think to grab keys from and have them ready for your process (everything is safe and secure, in memory).

You can get started with Teller right now – take it for a spin or build it from source.

The post The last mile of sensitive data appeared first on JAXenter.