2-Factor Authentication for Cloud-A

With the growth and adoption of Cloud-A’s infrastructure services around the world, having thousands of active projects, and twice that number of active users — our responsibility to provide a secure entry point into the services that store your application’s private data, that help run your businesses day-to-day, is greater than ever. With online threats growing, more advanced phishing techniques, and identity theft, ensuring secure access to any service becomes difficult. It doesn’t matter how long or complex your password is, your account is at risk of being breached if it were to somehow fall into the wrong hands.

1faTo this end, we are very pleased to announce the general availability of two-factor authentication for Cloud-A accounts. Our development team had been working on building an OTP solution into Keystone, our authentication service, and released it into beta late last year. After months of end-user testing, and security auditing by third parties, we are enabling the feature for all users.

Two-factor authentication, or 2FA, by its definition allows you to secure your account via a second “factor” rather than just a password. Because passwords can be read or stolen, and are a single piece of information that any malicious person needs to access your account, a second factor called One Time Passwords or OTP are used and linked to a physical device that is on your person — so you know that the person logging in is truly you. This added security will thwart would-be attackers even if they know your account password.

Available Today


2FA for Cloud-A allows you enable 2FA from within your Cloud-A Account Settings in the client portal. This will generate your private key and show you your QR code and recovery codes, as well as provide you with a quick OTP test mechanism to confirm your settings. Once enabled, you can use our 2FA with any Google Authenticator compatible mobile application. We highly recommend FreeOTP for managing your OTP credentials. It is free, secure, standards-compliant, and open source. The app is available for download on Google Play for Android, as well as the App Store for iOS devices.

As previously noted, Cloud-A’s 2FA architecture is built into Keystone, meaning that two-factor authentication is available at both the web dashboard level and also at the API layer. The result is a completely new architecture, and new way to approach OpenStack authentication. We hope that this not only shows our commitment to on-going product development for our customers, but our commitment to the OpenStack project as a whole.

Users will not be forced to enable OTP on their accounts, however we highly recommend setting it up. You can read more information on the configuration process in our documentation portal. Taking a few minutes to enable this feature on your account could mean the difference between an adversary accessing your account and gaining access to your cloud infrastructure, and stopping them right at the door.

If you have any questions or concerns about configuring 2FA on your account, we’d love to hear from you! You can reach our support team quickly and easily by emailing support@clouda.ca.

Announcing Cloud-A Managed Security Services

Managed-Security-Services1-396x196A few months back we released our Web Application Security Survey and were amazed at the amount of participation we had – it was the single greatest amount of feedback we have ever received at one time, which helped us realize that security is a very important topic for our users that has been unaddressed. From this data we were able to determine two main things. Either developers:

A) Don’t have confidence in their own security measures and procedures

B) Don’t have the time to spend implementing security best practises

While we were not entirely surprised with the results of the survey, it helped us realize that there was a gap in our user’s understanding of the Cloud-A security partnership model, and there was a gap in our offering to help our users better secure their environments on Cloud-A.

Read more

Cloud-A at the Atlantic Security Conference

This week the Cloud-A team will be at the 5th annual Atlantic Security Conference in Halifax, Nova Scotia. The Atlantic Security Conference was recently listed as one of The Top 50 Must-Attend Information Security Conferences in the world by Digital Guardian, and we are looking forward to interacting with Atlantic Canada’s infosec community, representing the OpenStack community and promoting the use of true cloud computing.

This year Cloud-A is offering a free one hour DevOps consulting session for any organization who attends AtlSecCon and signs up for a Cloud-A account.

Stop by our table and say Hi! For anyone unable to make it, check our twitter account (@CDNCloudA) for live AtlSecCon updates.

Linux security best practices for running your server in the cloud

At Cloud-A we enable our users to signup and manage their own infrastructure, giving them full control to configure and secure their own instances, networks and storage as they wish. We like to provide tips, tricks and best practises to give you the information you need to ensure that your instances are secure. Here are a few best practises for hardening and securing your Linux instances on Cloud-A.

Eliminate Unneeded Service

  • Do not run any unneeded services such as FTP.
  • If you are running DNS, be sure to close it off from being an open resolver so that you do not become part of a DDoS attack.

Lock down SSH

  • Disable root login via SSH
  • Only allow specified IPs to connect via SSH
  • Only allow SSH Key based authentication  – Do not allow password authentication
  • Use an alternative SSH port

Use fail2ban


  • Use fail2ban to automatically add malicious IPs to the firewall drop rules.

Update packages on regular basis

  • Keep your packages up to date to avoid being susceptible to zero day attacks.

More Links:









Whether it is for compliance purposes, protecting trade secrets, or safeguarding sensitive client information, data security is a priority for every organization in any industry. With the rapid adoption of public cloud environments, it is imperative to understand how cloud affects how you secure your data. At the most basic level, it is understanding which parties are responsible for the different layers of security, so to clarify how this works with Cloud-A, we have created the Guide to Securing Your Data with Cloud-A.

It is Cloud-A’s responsibility to ensure that our infrastructure is bulletproof and that we follow security best practises, but once a client launches an instance, they have free reign to manage their cloud infrastructure as they please.

Here are some best practices and client responsibilities for securing your data with Cloud-A

Passwords 101

Password strength is the most basic layer of security in any scenario, but it is of the utmost importance. Weak passwords are a simple point of failure that the most amateur attacker can take advantage of. A strong password should be between 10 and 12 characters, it should have a mixture of uppercase and lowercase letters, as well as numbers and symbols. There are tools available to assist with creating and keeping track of your passwords.

Check out LastPass

Encryption is Key

Although the infrastructure that your Cloud-A instances reside on and the OpenStack platform that orchestrates and manages that infrastructure is built and managed with security as the top priority, it is the users responsibility to ensure that the drives of their cloud servers are protected. We recommend encrypting the drives (volumes) that are attached to your Cloud-A instances.  Encryption is a great way to keep your valuable data safe at rest, as it make your data unreadable to any unintended recipient. For more details on configuration and benefits, you can check out our blog post:  Encrypted Volumes: Linux Edition

Lock Down Security Groups

Cloud-A’s security group functionality allows you to create firewall rules that can be applied to your instances. Instances are launched with all of the ports locked down and you can create your own firewall rules that you can allocate to your instances. It is important to use inclusive firewall rules rather than exclusive. Exclusive firewall rules allow all traffic through except for the traffic matching the ruleset. Inclusive firewall rules do the reverse as they only allow traffic matching the rules through and block everything else. When creating your firewall rules, It is best practice to only allow internet access to servers that require it. You can use your internal networks created with Cloud-A’s virtual private networking to connect servers that do not require internet access.

Understand that Cloud Security is a Partnership

Once you launch an instance on Cloud-A, you have full control over that virtual machine. It is up to the end user, or the Cloud-A integration partner to manage that virtual machine, ensure that it is patched, updated and that it is used appropriately. There is a level of knowledge that is required to operate a server securely. If you do not have that level of knowledge in-house, we advise that you seek out an organization that can provide these services. Cloud-A can help recommend partners who can assist with these services. Many organizations with stringent requirements for data security require advanced security services such as intrusion protection and detection and live security monitoring. Cloud-A’s go-to security partner for these advanced security services is GoSecure.



We have been receiving a lot of questions from prospective partners about how we comply with the rules around private information as it pertains to healthcare in Canada. The simple answer is that we provide secure and redundant infrastructure to our healthcare partners and work with them to recommend best practices and procedures for securing their own virtual instances that reside on our public cloud.

While that explanation might seem broad for such an important topic, the laws pertaining to personal information protection in Canada are complicated, technically nonspecific, and just plain hard to grasp.

We have created this “Guide to Protecting Private Healthcare Information in the Canadian Public Cloud” to help inform our partners and clients about how they can use our public cloud and be in compliance with Canadian privacy laws.

Download Cloud­-A’s Guide to Protecting Private Healthcare Information in the Canadian Public Cloud

Encrypted Volumes: Linux Edition

Having your data encrypted at rest is crucial for a secure application, especially when you are reporting to a governing body for IT security standards in the Healthcare or Financial markets. Our VPC networking ensures all private network traffic is fully encrypted per customer network, which ensures your data is encrypted over the wire between VMs. Having encrypted volumes will add an extra layer of security to ensure even a somehow compromised volume is rendered unreadable.

We’re going to review encrypting your Cloud-A SSD volume on both a Redhat based, and Debian based Linux distribution using the dm-crypt package — the gold standard for modern Linux disk encryption. dm-crypt is a kernel level transparent disk encryption system, only worrying about block level encryption without ever interpreting data itself. This gives dm-crypt the availability to encrypt any block device, from root disks and attached volumes, to even swap space.

Create your SSD Volume

Head to your Cloud-A dashboard, and create a new Volume under “Servers -> Volumes”. We’ll create a 120GB volume named “Encrypted Disk 1?.

Screenshot - 11172014 - 02:10:52 PM

Now that we have the drive in place, we’ll attach it to a server to configure the disk encryption.

Screenshot - 11172014 - 02:11:51 PM
Screenshot - 11172014 - 02:14:27 PM

Linux Setup: Ubuntu 14.04 & Fedora 20

Our Ubuntu and Fedora images ship with the necessary tools to do encryption out of the box, we’re going to use the cryptsetup package to create the encrypted block device, create a password, and make it available to mount via the mapper.

sudo cryptsetup -y luksFormat /dev/vdb

Cryptsetup will prompt you to overwrite the block device, and be irreparable. Type “YES” in all caps to confirm. You’ll next be asked to provide a password for decrypting your data, make sure you choose a strong password and store it somewhere safe.

If you lose your password, you will in effect have lost all of your data.

Now we can use cryptsetup luksOpen to open the encrypted disk, and have the device mapper make it available. When you run this command, you’ll need to provide the password you entered in the last step.

sudo cryptsetup luksOpen /dev/vdb encrypted_vol

Next, we’re able to interact with the disk per usual at the /dev/mapper/encrypted_vol location created in the last step. Since the encryption is done transparently, you don’t need to do anything special from here on out to keep your data encrypted and safe. We’ll create a simple journaled Ext4 filesystem, and mount it to /data for the application server to use.

sudo mkfs.ext4 -j /dev/mapper/encrypted_vol
sudo mkdir /data
sudo mount /dev/mapper/encrypted_vol /data

Your disk is ready. You can check that it’s mounted and how much space is available using df -h.

Filesystem                 Size  Used Avail Use% Mounted on
/dev/vda1                   60G   22G   38G  36% /
/dev/mapper/encrypted_vol  118G   18M  112G   1% /data

You can now configure your database data directory, or application user data to point to your new encrypted /data directory to store your sensitive data.

Next Steps

When you are done with the volume, you can close it by unmounting and using luksClose to remove the mapping and deauthenticate the mount point so it cannot be accessed until re-authenticating.

sudo umount /data
sudo luksClose encrypted_vol

And to re-authenticate in the future on this, or any other VM you simply need to use luksOpen with your decryption password and mount to your desired location.

sudo cryptsetup luksOpen /dev/vdb encrypted_vol
sudo mount /dev/mapper/encrypted_vol /data

This should help you get on your way to a more secure installation of your application with securely storing your application data on a high performance SSD volume. At any time, you can use the Volume Live Snapshot function in the dashboard to capture a snapshot of this volume to maintain encrypted backups that you can restore to a new volume at any time.

Encrypted disks are not the only security measure you should be taking into account when deploying your infrastructure, but it is a crucial step in the right direction for every security conscious deployment scenario.

Our Commitment To You (Our Clients) On Data Privacy

It was a fortunate coincidence that not too long after we started up Cloud-A, Snowden came out with all the information about how data privacy was at risk, more than almost anyone would have thought possible at the time. Shortly after that it became clear that Canada is not without its challenges in this area as well. We see this kind of interference clearly as abuse, that will hopefully one day be corrected and seen historically as a very unfortunate oversight that as of today is in great need of being rectified.


Our values are simple and very straight forward: everyone should have the right to privacy unless they are doing something that is illegal. In that case the legal process dictates that the authorities who are conducting an official investigation have the right to collect data for the purposes of that investigation that is bound and defined by way of a warrant. In our view, to provide anyone any of our clients’ data without a warrant or their consent would be not only unethical but would also be a violation of our clients’ fundamental right to privacy.

In addition, we are committed to telling our customers about all government data requests. We promise to tell users when the government seeks their data unless prohibited by law. The idea being that this gives users a chance to defend themselves against overreaching government demands for their data.

To be fair, we have not had very many requests for this kind of thing so far. We think that’s a good thing, it tells us that our users are by in large not doing anything that would give anyone cause for concern in this way, and it also tells us that the authorities are not as overly ambitious as compared to what it sounds like happens in other regions. That being said, we know that with our continued growth it’s just a matter of time before this kind of thing will be more relevant for us and our clients in the future. As a result, we thought it would be appropriate to make a comment about our intentions moving forward.

In addition to protecting our clients’ privacy to the extent of our legal abilities, we are committed to publishing statistics on how often we provide user data to the government in general terms.