MSPOG – Accepting the Reality of Multiple Single Panes of Glass

You probably dread the phrase as much as I do. We hear it all the time on a sales call or a product demo: “this is the single pane of glass for you and your team”. The problem is that I’ve been working in the industry a long time and have been using a lot of single panes of glass…at the same time. Many of my presentations have been centered around the idea that we must embrace the right tool for the right task, and not try to force everything through one proverbial funnel because the reality is that we cannot do everything with any single product.

For this reason, it’s time to embrace MSPOG: Multiple Single Panes of Glass

Many Tools, Many Tasks, One Approach

Using a unified approach to something is far more important than the requirement to using a single product to do it. I’m not saying that you should just willy nilly glue together dozens of products and accept it. What I am saying is that we have to dig into the core requirements of any task that we performa and think about things in a very Theory of Constraints (ToC) way. Before we even dive into some use-cases, think about what we are taught as architects: use the requirements to define the conceptual, logical, and then physical solution. All the while, understanding and making our decisions based on risks and constraints.

If you have a process that requires two or three different processes within it, you may be able to use a single tool for those processes. What if one of the processes is best solved with a different tool? This becomes the question of the requirements. Is it a risk if we embrace a second tool? More importantly, is it a risk or a constraint to use a single tool? This is the big question we should be asking ourselves continuously.

Imagine a virtual machine lifecycle process. We need to spawn the VM from a template, give it a network address, deploy an application into it, and then make sure it is continuously managed by a patch management and configuration management system. I know that you’re already evaluating how we should do this at the physical level by saying “use Ansible!” or “use Puppet!” or “use vRealize Automation!”. Stop and think about what the process is from end-to-end.

Our constraints on this is that we are using a VMware vSphere 6.5 hypervisor, a Windows 2016 guest, and using NGINX and a Ruby on Rails application within the guest.

  1. Deploy a VM from template – You can do this with any number of tools. Choose one and think about how we move forward from here
  2. Define IP address – We can use vRO, vRA, Puppet, Chef, or any of a number of tools. You can also even do some rudimentary PowerCLI or other automation once the machine is up and running
  3. Deploy your application – App deployment can be done with something like Chef, Puppet, or Ansible, as well as the native vRO and vRA with some care and feeding
  4. Patch management – Now we get more narrow. Most likely, you are going to want to use SCCM for this one, so this is definitely bringing another pane of glass in
  5. Configuration management – Provided you use SCCM because of the Windows environment, you can use that as well for configuration management…but what about the nested applications and configurations such as websites and other deeper node-specific stuff. Argh!!!

Even if you came out of the bottom of those 5 steps with just two tools, I would be thinking you may need to reevaluate because you have have overshot on the capabilities of those two tools. It is easy to see that if we start narrowing to a single pane of glass approach, that we are now jamming square blocks into round holes just to satisfy our supposed need to use a single product.

What we do need to do look for the platforms within that subset of options that has the widest and deepest set of capabilities to ensure we aren’t stacking up too many products to achieve our overall goals.

The solution: Heads up Display for your Single Pane of Glass

Automate the background and display in the foreground. We need to think more about having the proverbial single pane of glass be a visible layer on top of the real-time activity that is happening. Make your toolkit a fully-featured solution together with focus on how you can do as much as possible within each product. Also, reevaluate regularly. I can’t even count how many times i’ve been caught out by using something a specific way, only to find out that in a later version that the functionality was extended and I was using a less-desirable method, or even a deprecated method.

There is a reason that we have a mainframe at the centre of many large infrastructure shops. You wouldn’t tell them to shed their mainframe just to deploy all their data on NoSQL, right? That would be lunacy. Let’s embrace our Multiple Single Panes of Glass and learn to create better summary screens to annotate the activity. This way we also train ourselves to automate under the covers and trust the underlayers.

I, for one, welcome our Multiple Single Panes of Glass.


Image source:

Why your Security Products are Inherently Insecure

You’re being sold snake oil every day in the world of IT. It is about time that we just lay this out honestly. The products that you are buying are not solutions. They are methodologies. Why does this semantic difference matter? It matters because we are blindly putting tools into place under the assumption that they are a solution to a problem. The truth is that they are merely tools in the fight to solve the problem.

Conceptual – Logical – Physical

Go back to the basics of systems architecture and infrastructure design for a moment. We view things in three stages of the design process as conceptual, logical, and physical. Conceptual design is thinking at a high level on the goal such as “the application servers will be protected from intrusion”. Moving to the logical physical version to expand on that concept would be something like “Layer 4-7 firewalls will be deployed at the ingress and egress point for the application servers”. Getting down to the physical is something like “Product X will be deployed to provide layer 4-7 firewall protection” which is the result of designing to meet the first two requirements.

The issue that we face as an industry is two-fold. First, we often start at “Product X will be deployed” without having done the due diligence on what the actual business and technical requirements are which need to be solved. The second issue is that we buy Product X, deploy Product X, and then everyone goes for a project completion dinner and celebrates that we have finished up the deployment with the bold assumption that we are inherently secure.

Many organizations are buying products or embracing some new technologies into their environments based on a promise. Promises should always bear translated to assumptions. I’ll start with one that I am seeing a lot of lately which is this:

“Containers are more secure for applications than virtual machines”

This is both true and false at the same time. The wording is important. What the phrase should say is “containers have the ability to be architected and deployed to be more secure for applications than traditional virtual machines”.

Here’s why phrasing is important.

Why is your security product inherently insecure?

You can’t buy a bow and arrow and suddenly you are an archer. The same goes for security. Just because you have bought a security product, it does not mean that you are secure. It’s actually the polar opposite. Your environment is inherently insecure. Even if you are absolutely sure that you are deployed in the most secure manner possible, you should ALWAYS ASSUME that you have been breached.

What’s the solution for this? This comes in three forms:

  1. Accept that you are insecure and build processes around that assumption
  2. Deploy and continuously test your security platforms
  3. Engage third-party testers and products to ensure continuous objective testing

Let’s dive into these three areas a little bit further.

Accept that you are insecure and build processes around that assumption

Point 1 is the key to begin with. Assume you have been breached. Now what? How are you aggregating your logs? How are you protecting the logging both locally on the application endpoints as well as in your central logging environments? If you have to assume that your ingress has been compromised, you also have to assume that your log environments have been compromised as well. You need local protection on each system plus centralized, read-only aggregation with regular snapshots of that environment to ensure its integrity too.

The build process you use will inevitably call on some external dependencies. It could be patches, software updates, or any of a wide variety of files and applications. Assume that these are inaccessible or compromised as you define your programmatic build process to use locally cached data and application dependencies as much as possible. And yes, the programmatic build process is key to ensuring consistency and security. You should include checksum and signature detection for all source files as you put them into the virtual application instances.

Deploy and continuously test your security platforms

Test-driven development is a great methodology. I have long been a user and a proponent of what is known as test-driven infrastructure and this includes the need for security as a part of the cycle. The only way that you know your detection system is working is if you test it when there is an issue. Assuming detection without truly testing the response means that you are relying on the assumption. Your CISO does not rely on assumptions, and neither do your customers.

Whichever products you embrace in your IT security portfolio, they will inevitably come with some form of baked in testing procedures and processes. Be aggressive and adamant with your vendors that this is a requirement for you. Nobody wants to be caught going back after a vulnerability to have to find out that it was detectable and preventable.

Engage third-party testers and products to ensure continuous objective testing

I hire someone to do my taxes. Yes, I can do them myself. That doesn’t mean that I’m an expert and can find every advantage within the tax code to get the best results. Why would I treat security and vulnerability testing any differently than any other discipline in my business and IT organization. Using 3rd party companies will give you the ability to lean on them for expertise, and most importantly, certification and validation of your security stance in an active environment.

Having spent years in financial services environments which have stringent requirements around auditing and security, I can tell you that no matter how secure even the IT security team thought they were, a 3rd party can come in and teach some rough lessons in a couple of hours.

Turn Assumptions into Actions

Going back to the example that containers are more secure than virtual machines gives us a great one to work from. Containers typically run thinner and provide a smaller attack surface for vulnerabilities, malware, and other attacks by bad actors. No, not Lorenzo Lamas, but anyone who is attempting to breach your environment. We will usually hear them being referred to as bad actors.

The truth is that containers as a construct, are solving deployment challenges first. Security is a secondary win that implies you have the practices in place to assure that security is greater than that of a traditional virtual machine. Containers are leveraging namespaces and other methods if isolation with the underlying server host to provide some potentially powerful protection. It does not mean that by default the container version of your application is more secure. It means that at the lowest possible layers, not including poor application code, SQL injection, XSS and many of a thousand different other attack vectors are solved by deploying in a container versus a traditional virtual machine.

The long and the short of it is that security products, or any technology products for that matter, are inherently insecure unless you deploy them with all of the practices in place around them to ensure the security.

This conversation on Twitter is a nice way to show how challenging it is to convey the message:

Using Terraform to Install DevStack on DigitalOcean

There are a few times where having a persistent OpenStack lab on a shared infrastructure is handy. I’ve been revisiting DevStack a lot more lately in order to help a few folks get their labs up and running. DevStack is the OpenStack project which lets you run non-production OpenStack using either a single or a multi-node configuration. Running on DigitalOcean means that I can have a lab that can spin up quickly (about 40 minutes) and also lets me find another handy use for Terraform.

NOTE: This uses an 80$/month DigitalOcean droplet, so please keep that in mind as you experiment.

Requirements for this are:

Getting the Code

All of the scripts and configuration are on GitHub for free use and are also open for contributions and updates if you see anything that you’re keen to add to. Remember that Terraform uses state files to manage your environment, so when you pull down the GitHub repo and launch your environment, it will create the .tfstate and .tfstatebackup files after you launch for the first time.

Grab the code using git clone to bring it down locally:

Change directory into the /terraform-samples/DigitalOcean/devstack folder where we will be working:

Make sure you have the environment variables setup including the DigitalOcean API token, SSH key file locations, and your SSH fingerprint. These can be exported into your environment using a script or as one-off commands:

The process that is run by the code is to:

  • Pull the DigitalOcean environment needs (API and SSH info)
  • Launch an 8 GB RAM droplet in the NYC2 region and attach your SSH fingerprint
  • Insert the DevStack build script (files/ as a cloud-init script

Those are the pre-requirements. Now it’s time to get started!

Launching the DevStack Build on DigitalOcean with Terraform

It’s always good to use a health check flow of your Terraform builds. Start by validating, running the plan, and then launching. This ensures that you have a good environment configuration and the process should work smoothly.

terraform validate

No news is good news. The code validated fine and we are ready to run the terraform plan command to see what will transpire when we launch the build:

We can see a single droplet will be created because we have nothing to start with. There are a number of parameters that are dynamic and will be populated when the environment launches. Time to go for it!

terraform apply

This is where you need a little bit of patience. The build takes approximately 45-60 minutes. We know the IP address of the environment because we requested it via the Terraform outputs. You can confirm this at any time by running the terraform output command:

Checking the DevStack Install Progress using the Cloud-Init Log

Let’s connect via SSH to our DigitalOcean droplet so we can monitor the build progress. We use the build script as a cloud-init script so that it launches as root during the deployment. This means you can keep track of the results using the /var/log/cloud-init.log and the /var/log/cloud-init-output.log files.

Install completion is indicated by a set of log results like this:

Let’s try it out to confirm using the OpenStack Horizon dashboard URL as indicated in the cloud-init output. There are two accounts created by the script which are admin and demo, both of which have secret-do as the default password.

NOTE: Please change your OpenStack passwords right away! These are simple, plain-text passwords that are packaged with the build and you are vulnerable to attack

That gets us up and running. You are incurring charges as long as the environment is up, so when you’re ready to bring the environment down and destroy the droplet, it’s as easy as it was to launch it.

Destroying the DevStack DigitalOcean Build Using Terraform Destroy

In just two quick words and a confirmation we can remove all of the environment: terraform destroy

Just like that we have installed an all-in-one OpenStack DevStack node on DigitalOcean and learned another nifty way to leverage Hashicorp Terraform to do it.

Adding SSH Access for DigitalOcean when Using Terraform

We’ve been looking at how to add a little Terraform into your IT infrastructure provisioning toolkit lately. Using DigitalOcean is also super easy and inexpensive for testing out processes and doing things like repetitive builds using Terraform.

The first post where we saw how to do a simple Terraform environment build on DigitalOcean appeared at my ON:Technology blog hosted at Turbonomic. That gave us the initial steps for a quick droplet deployment.

We also talked about how to access your DigitalOcean droplets via the command line using SSH keys here which is very important. The reason that it is important is that without SSH keys, you are relying on using the root account with a password. DigitalOcean will create a complex password for you when deploying your droplet. This is not something you can find out without actually resetting the root password and restarting your droplet. This is both insecure (reverting to password access instead of SSH key pair) and also disruptive because you are rebooting the instance to do the password reset.

Now it’s time to merge these two things together!

Adding SSH key details to the Terraform DigitalOcean provider

We are going to add a few things to what we have already done in those two other posts. You will need the following:

Getting your SSH fingerprint is a simple process. Start by going to the top right of your DigialOcean console to the icon which has a dropdown for your account settings:

In the profile page, choose the Settings option from the menu on the left-hand panel:

The SSH fingerprint that you’ll need is in the security settings page. Keep this somewhere as safe as you would your SSH keys themselves because this is an important piece of security information.

Using the SSH Details in Environment Variables

Our settings are going to be stored using local environment variables just like with our DigitalOcean key was in the first example blog. Because we have a few other things to keep track of now we will see the changes in the file:

Our environments variables are going to have the same format which is TF_VAR_digitalocean_ssh_fingerprint which is your fingerprint you got from the security settings. The other two things we need are the TF_VAR_digitalocean_pub_key and TF_VAR_digitalocean_private_key parameters which are the paths to your local SSH key files.

NOTE: The use of the file locations is actually not needed for basic key configuration using Terraform. I just thought we should set that up which will come to use later on in other blogs around using Terraform with DigitalOcean.

Use the export command to sett up your variables.  Our Terraform file contains an extra config parameter now which you’ll see here:

These new parameters will read in all that we need to launch a new droplet, attach the appropriate SSH key by the fingerprint in DigitalOcean, and then to allow us to manage the infrastructure with Terraform.

Time for our routine, which should always be: terraform validate to confirm our syntax is good followed by a terraform plan to test the environment:

Now we run our terraform apply to launch the droplet:

Now we have launched a droplet on DigitalOcean with Terraform. Use the SSH command line to connect to the droplet as the root account. Make sure you’ve done all the steps in the previous blog to set up your ssh-agent and then you should be all set:

This is the next step in making more secure, repeatable, and compassable infrastructure using Terraform on DigitalOcean. These same methods will also be showing up as we walk through future more complex examples on DigitalOcean and other providers.

Let’s clean up after ourselves to make sure that we take advantage of the disposable and elastic nature of our public cloud infrastructure by very easily running the terraform destroy command to remove the droplet:

Hopefully this is helpful!

Accessing DigitalOcean Droplets via Command Line Using SSH Keys on OSX

As you get rolling with using DigitalOcean and other VPS providers, one of the features that many folks see in the configuration is the “user SSH key to access your instance” options. The trick is that many newcomers to using cloud instances aren’t totally comfortable or fully understand setting up an SSH key for password-less access to your instance.

Is it Secure Without a Password?

A resounding yes! In fact, it’s much more secure. You’ve uploaded the public side of your key to the instance already from within the cloud infrastructure and you’re now using the private side to match up for access. By not using a password, you’re removing the risk of sending authentication information over the public network. Brute force attacks are not as effective with public/private key pairs whereas they are successful in password hacking attempts.

It’s assumed that you’ve already uploaded your key. I won’t dig into all the different providers and ways to upload the keys. Make sure to do that for your individual provider to create and upload a key from your machine.

Adding your key to the SSH agent from the command line for OSX

When you launch your instance through the GUI, make sure that you have a SSH key selected to match the private key you have on your local machine. I’ve nicknamed mine as Eric-MacbookPro. For extra safety, I also keep copies of the keys in an offsite vault to ensure that I never lose access to the instances that are attached to that key.

When your DigitalOcean droplet is launched, the key is added as part of the init process. Once you have your IP address, you just have a quick process to run to set your key up. Because I use a key that is stored in a folder that isn’t the default, it has to be added to the ssh agent.

Run the eval `ssh-agent -s` command. NOTE: those are backpacks, not apostrophes. That character is found on the same key as the tilde (~) symbol.

The second command you run is ssh-add [yourkeyname] where [yourkeyname] is the full filename and path of your private key. IN my case, I have it stored in my Documents folder under a keys subfolder. This is my process:

ssh-add ~/Documents/keys/id_rsa

Connecting to your DigitalOcean Droplet via SSH with your Private Key

Now we simply run the command line ssh using the administrative account. For CentOS and Ubuntu on DigitaiOcean, it is the root account. For CoreOS instances, you use the core account.

My Ubuntu instance is accessible now by the ssh root@ip-address:

Now you’re in! Keep your keys safe, and keep your DigitalOcean droplets safe with those keys. Happy SSHing!

Platform9 Announces General Availability of Managed Kubernetes and Fission Project!

Since the launch of the company, which I was pleased to be able to cover a lot of exciting changes and growth with Platform9 over the last couple of years. What began as the OpenStack-as-a-Service focus has expanded to embrace both feature additions within the OpenStack offering as well as the addition of Docker and Kubernetes management.

Platform9 Announces General Availability of Managed Kubernetes

Kubernetes is gaining momentum in a way that has been unseen since Docker stormed onto the containerization scene in recent years. From much of what I’ve seen in the market and among customers and community members investigating container orchestration, Kubernetes has emerged as the de facto standard from what it seems at this point.

So, what does Platform9 bring to the table with managed Kubernetes? This is the ideal merger of bringing the k8s platform to an organization without the pain and overhead to manage:

  • complexity of architecting the infrastructure
  • operational overhead and engineering for resiliency
  • operational processes to maintain and upgrade the k8s control plane
  • risk of embracing the k8s platform

In the same way that Platform9 has simplified and delivered OpenStack using a SaaS model, we are seeing the same opportunity arise for folks to put container orchestration into their IT portfolio. The candidates who have been actively using the beta program for managed Kubernetes were a combination of both traditional virtualization shops, and more forward leaning container and cloud friendly organizations.

Having taken a few test drives with alternative products like the Amazon Elastic Container Service (ECS), I can easily see the attractiveness of Kubernetes, and even more so with a managed service approach. ECS gives the option for containerized workloads on your AWS environment, but it also means:

  • IAM integration that can be challenging (or poorly implemented)
  • proprietary nature of the container lifecycle on ECS
  • “lock-in” which is a result of the proprietary stack and workflows
  • one-destination for your infrastructure (build on ECS…for ECS)

Container and cloud friendly organizations are already embracing the value of automation, and will be likely to also have many more open technologies as a part of their IT portfolio.

The full details on the new offering are available here at the Platform9 website.

Platform9 Announces the Fission Project

The Serverless phase of infrastructure is becoming one that is getting a lot of attention. Many push back on the importance of it mostly out of the fear that it is only going to be available as a cloud-based service, or that running the infrastructure requires a lot of care and feeding which may offset the benefits in some ways.

What if we just want to run code, and not have to worry about all of the tooling underneath the covers? With K8s already on board, there is now an excellent option to provide Functions-as-a-Service (FaaS), or what we know as Serverless infrastructure, using Fission for Kubernetes.

When you installed Docker the first time and typed “docker run”, you saw a little magic happening. We call that the “Aha! moment” where you realize that this is something very cool that is also only the beginning of the possibility for it. Kubernetes takes a lot more care and feeding to get to that point, but once you’re there you are going to realize how easy it is to consume as an abstraction layer above the infrastructure.

Now that Kubernetes is under the covers, you can also add Fission into the mix and bring another very interesting open source platform into your arsenal of tools.

The challenges being solved by Fission include:

  • moving to code-only deployments for development
  • Lambda-like functionality on-premises or wherever you have k8s running
  • Bring Your Own REST functions capability

Because this is open source, we are already seeing innovation leading up to the official launch. Python and Node.js were built in as out of the box languages to be supported, and soon after the publishing of the project to GitHub there was a Pull Request to add C# support when running .NET core. That, my friends, is the power of community!

The full details on the Fission project are available at the Platform9 site and we can look forward to lots of activity in this area in the coming months if my predictions are correct. I sure know that I’ll be digging into it myself!

Thanks to Sirish Raghuram for the briefing on the announcement, and congratulations to the Platform9 team on this very cool release.

Keep watching here as we take a deep-dive into the managed Kubernetes offering over the next couple of weeks.