Security & SkyPlug

Automation and simplified management is great, but it can’t come at the expense of security. Headlines provide daily reminders of the importance of security in the face of persistent cyber threats against businesses and individuals. SkyPlug is designed and operated with best practices that protect the security of your infrastructure while providing the efficiency of automation.

Read on for details about the security features of SkyPlug. Questions or concerns? Don’t hesitate to get in touch.

Big Picture

At a high level, SkyPlug is an automation engine that performs work on your cloud resources (e.g. starting and stopping virtual machines) on your behalf. To do this, the SkyPlug service must be granted access to those resources. Once access is granted, SkyPlug operates via the Azure API to discover information it needs to do its job and perform those jobs as directed by you.

In this sense, you can think of SkyPlug as another user in your organization. Just as you would grant appropriate access to a team member to manage resources in an Azure subscription, you grant SkyPlug limited access to specific subscriptions where you want it to manage virtual machines. Just as a user is required to log in with credentials to the Azure portal, SkyPlug authenticates itself each time it accesses the Azure API. Just as a user would learn some things about the contents of a subscription, so does SkyPlug.

From a security perspective, the same basic considerations apply when thinking about an integrated service like SkyPlug as apply to adding a new team member to your access list. In particular, this means protecting credentials, securing data and being careful with access privileges.

Let's dig in.

Integration: Connections and Delegation

The first step in putting SkyPlug to work is getting it connected to your resources in Azure. This involves creating a “connection” to one or more Azure subscriptions that you manage.

What does such a connection involve? Essentially, it’s equivalent to granting access to SkyPlug as a user (or more specifically, as a service principal). Here’s how it works:

  1. From the SkyPlug dashboard, you begin the sequence to connect to a subscription
  2. You are redirected to Microsoft to authenticate via the OAuth 2.0 protocol. This involves providing your credentials directly to Microsoft’s systems to prove your access to Azure. SkyPlug has no access to this communication and never sees your Microsoft account password.
  3. Microsoft redirects you back to SkyPlug with a token that it can use to temporarily access Azure on your behalf (this is “consent”).
  4. On your behalf, a new entry is made to your Azure subscription access list which grants limited privileges to SkyPlug to perform operations on virtual machines (via the “Virtual Machine Contributor” role).
  5. At this point, SkyPlug has ongoing access to the subscription to perform discovery and automated actions.
Azure Resource Manager Role for SkyPlug

Resource Types (Classic vs. Azure Resource Manager)

The above results in access via the Azure Resource Manager (ARM) API, which is the newer method of access to Azure resources. Unfortunately, Microsoft introduced this alongside a previous and completely separate API and resource model, which is often described as pertaining to “classic” resources and the “service management” API. This legacy API requires the use of certificates for access and cannot use the newer role-based permissions.

There are two implications to this split. First, if you want to manage “classic” virtual machines, you’ll need a legacy connection implemented via a management certificate. Second, this access model gives clients (including SkyPlug) wide access to the subscription, since there is no concept of limited roles in the legacy API.

Given the limitations, we recommend migration away from using classic resources in Azure and instead using the newer ARM virtual machines and other resources. But if you have existing classic VMs that you want to manage with SkyPlug, you can do that as follows:

  1. From the SkyPlug subscription connection, choose “Manage Certificate”.
  2. A unique public certificate will be generated and provided for download.
  3. In the classic Azure portal, upload as a new management certificate in the subscription settings.
  4. At this point, SkyPlug as ongoing access to the subscription via the legacy API to find and act on classic resources.
Azure Management Certificate for SkyPlug

Some important aspects about certificate management with Azure in general and SkyPlug in particular:

  • In general, private keys should be treated with care and not stored or allowed outside of your control. SkyPlug generates a unique private/public key pair for each certificate and stores the private key encrypted with AES in its secure database.
  • The private key is never shown to anyone, including you or SkyPlug administrators, and is only used momentarily during authentication to Azure over a secure connection.
  • The downloaded certificate contains only the public key and does not require special protection.

Ongoing Access and Revocation

Once the connection is created, you’ve effectively delegated the management of your virtual machines to SkyPlug, and it is able to access the resources on an ongoing basis without your presence. What if you want to ensure such access is revoked for any reason? That can be done simply and completely by:

  • Removing the SkyPlug service principal entry from your subscription’s access list
  • Deleting the SkyPlug management certificate, if installed, from your subscription’s settings page

Keys and Certificates

Once connections are established to your Azure subscriptions, SkyPlug authenticates to Azure using either a service principal id and key, or a management certificate with private key. In both cases, the keys represent the secrets that SkyPlug holds securely in the server. The keys are protected from access via Azure authentication and access control mechanisms. Keys are never present in source code or outside the isolated runtime environment.

Authentication & Role-based Access

When you create your SkyPlug account, you’re asked to create a strong password for keeping your access secure (long and random string of characters). Reset requests for forgotten passwords are sent to an email address you control.

With a Team plan, you can also add other members of your team to your account. The initial user is a full administrator and subsequent users can be assigned a role or custom set of permissions to limit their access and actions. Custom roles can be created to match required access. For example, you might create “Read-Only” role the has no ability to make any changes in the account.


Maintaining the confidentiality of data is table stakes when it comes to security on the web. High quality cryptography is used throughout the SkyPlug system:

  • Secure HTTPS connections from you to the entire site and API
  • Secure HTTPS from SkyPlug to Azure
  • Data encrypted at rest in and to/from the database
  • Salted and hashed passwords for user accounts
  • Encrypted private keys for certificates
  • Secure access by developers and administrators to Azure

We believe in the principle: nothing sensitive in the clear at any time.

Data Safety

In order to perform its duties as your faithful automation engine, SkyPlug learns a few things about your Azure resources, many of which are displayed to you when you view the application dashboard. This includes basic details about the virtual machines you make available to SkyPlug for management, like names, identifiers, and other metadata. SkyPlug doesn’t store anything about your environment that would be particularly sensitive or useful to attackers – it has no knowledge of credentials to your virtual machines or account payment information, etc.

Even so, all the data in the SkyPlug database is encrypted at rest and in transit using SQL Azure security features. Moreover, access to the database itself is limited to specific users and IP addresses, and has no public exposure.

What about payment information for customers with paid plans (we love you!)? This actually never touches SkyPlug servers, because we use Stripe for payment processing. When you submit your credit card information, it is sent encrypted directly to Stripe – SkyPlug doesn’t know your card number or anything else, and it is quite happy about that.


What about the SkyPlug servers themselves? They run in Microsoft’s Azure datacenters (in the U.S.), just like your infrastructure. Thus, they benefit from the same physical and operational security that comes with Microsoft’s facilities and practices.


While it’s obviously necessary to protect against unauthorized access, an aspect of security that can be just as important is to keep tabs on authorized use. This is where auditing comes into play. SkyPlug facilitates auditing in two ways, internally and through Microsoft’s inherent auditing in Azure.

Within SkyPlug itself, usage is audited for all users, keeping record of important events that occur like logins and changes. This audit history is available for historical review and searchable for ease of analysis.

Within Azure, Microsoft keeps audit records for API access and will show actions performed by SkyPlug. We encourage you to review your audit logs regularly (as we do) to ensure SkyPlug (or anyone else) isn’t up to any shenanigans.

Azure audit logs of SkyPlug actions

More Questions?

We’d love to chat! Drop us a line.