Like walking into The Matrix, that’s how I felt when I first stepped foot in the data center that houses our main CloudGate servers. It’s a strangely eerie place, requiring visitors to make a lengthy walk through the forbidding hallway pictured above, all the way up to the reception desk in the distance. Gaining access to the data center’s innards requires biometric authentication and the possession of a key card, verified both by the data center’s systems and a somewhat stern-looking security guard. The message is clear: the data center takes security very seriously, and so should you.

In recent years, however, more and more organizations are moving part or all of their IT infrastructure from dedicated server rooms and data centers into the cloud. Cloud service providers—such as Amazon Web Services (AWS)—provide on-demand computing resources that often allow new server instances to be configured and launched with the click of a single button.

The convenience and inherent security that AWS promises, can however become somewhat of a double-edged sword, as it can cause administrators to lose sight of where the cloud service provider’s responsibility ends and their own responsibility begins. Moreover, the ease-of-use provided by AWS and similar services allows a new class of users to enter the world of IT operations—users who sometimes lack required knowledge and are not fully aware of the security implications of their actions. Lastly, because most cloud providers offer convenient APIs and CLIs to access their services, we are witnessing an acceleration in the ongoing trend of automated infrastructure orchestration, allowing large-scale application and network topologies to be deployed with little to no human intervention. As more and more systems interact with other systems, keeping track of the various keys and passwords that are required for authentication and authorization increasingly becomes a challenge.

The issues outlined above lead to a number of problematic situations: developers inadvertently publish their AWS access keys on GitHub, AWS accounts frequently get compromised, and even companies that are in the IT security business regularly get breached and have their (and their customers’) data stolen. There clearly is a problem, and because we are seeing an increase in usage of AWS and other cloud services by our customers, we have been working hard on deepening the integration between CloudGate UNO and AWS.

Accessing the Amazon Web Services Management Console

For most users, the AWS Management Console is the primary point of access to AWS. Amazon does provide a number of multi-factor authentication (MFA) form factors to further secure access to the console, but with the majority of users still relying on username/password authentication, they have arguably not seen the widespread adoption that they deserve.

Besides offering multi-factor authentication solutions, AWS also supports identity federation and allows single sign-on (SSO) access to AWS accounts using the Security Assertion Markup Language 2.0 (SAML) protocol. CloudGate UNO, by virtue of being an SSO provider, supports this protocol and currently already allows customers to log in to their AWS Management Consoles. This further allows CloudGate administrators to set up access restrictions and biometric or two-factor authentication to limit and secure access to the AWS account.

Generating temporary access keys for the Amazon Web Services API & CLI

For more integrated scenarios, instead of manually configuring and spinning up instances through the Management Console, users tend to rely on the various APIs and CLIs provided by AWS. It goes without saying that executing a request through an API or CLI also requires authentication and authorization, and, to achieve this, the AWS SDKs and CLI tools make use of so-called access keys to sign these requests on behalf of the user.

AWS access keys are typically created by users in the Management Console, and then copied to the file system to later be used in API or CLI requests. Because access keys can typically be used indefinitely, there is no incentive for the user to regularly replace or rotate their keys. These long-lived keys are habitually shared with other users, sent over email, committed to public code repositories, or left behind on various drives and devices.

The obvious solution to this problem, besides introducing stringent key management policies on the organization level, is to restrict the validity of these access keys in time. The goal here is to ensure that, by the time an access key eventually find its way into the hands of an untrusted party, it has long since expired and rendered useless. Conveniently, AWS provides a mechanism to issue temporary access keys, and has integrated this with its identity federation services.

As part of our ongoing integration efforts with AWS, we are currently finishing up the implementation of a set of features for CloudGate UNO that will allow users to retrieve temporary access keys from AWS, much in the same way as they use CloudGate to log in to the AWS Management Console and other services.