Cloud

Command temporary access through AWS CLI

14 December 2020 • 3 min read

Command Temporary Access Through AWS CLI (1)

Infrastructure security, like all security, exists in a constant tension between granting and preventing access. Access is necessary – but make access too easy and the results could be disastrous.

There is plenty of logical best practice for controlling which accounts have access to data, and for monitoring and reporting unusual activity and setting use of authentication methods. However, when it comes to creating, maintaining or fault-finding within the infrastructure itself, it is common for developers, contractors or other specialists to need access to systems and data beyond their normal access.

Unfortunately, a temporary need might result in access that persists. For example, it might be necessary to examine the number and size of objects in an S3 bucket prior to a migration or when scoping infrastructure bounds. But it’s inappropriate to grant secrets with indefinite duration, even if no accidental or deliberate harm occurs. It’s easy to violate regulatory, compliance and auditing requirements when temporary access credentials must be manually revoked.

There is, however, a mechanism to manage such temporary access and give clearly defined limits – in both time and scope – in an auditable way that integrates with standard AWS reporting. We frequently use these methods at AND Digital and recommend them to our clients as best practice.

Temporary access management in practice

Let’s take an example using the standard tools available to us. This is just one way of doing it, and your organisation may differ in the details. But the principles will be the same: generate a time-limited token from a federated access controller and let it work with AWS.

We use Okta for workforce identity management.

  • The first step is to get Okta to use Security Assertion Markup Language (SAML) to log into AWS’s Identity and Access Management (IAM) system.
  • Then ask AWS’s security token service (STS) to generate a set of session credentials that will grant access to AWS resources - this is the set of standard messaging and management functions that ensure tokens are properly used and managed in the system.

There’s a lot of detail to get right – none of it onerous. Anyone contemplating this process will need a good knowledge of how to create roles with trusted entities in SAML, and how to build configuration files, wrappers and run tools via Amazon’s Command Line Interface (CLI), so this process falls within the purview of properly skilled admins with explicit security roles. The important extra parameter to set up when generating the access tokens is their limited duration, setting the automatic retirement of their access privileges at the required time.

Not just the right tools, but the right people

This is where the necessary trust comes in. Your system admins will have widespread – albeit appropriately limited – access to key infrastructure and data. They are therefore the appropriate points in the organisation to understand and grant temporary access to others. If there is a legitimate reason to grant extensions of access, they are absolutely the right people to assess such a request. It is appropriate that the creation of such access is a technical matter, rather than an automated function or a simple form-filling exercise. Best practice is as much about the managing of trust and enablement as it is about restrictions.

Need to know more?

AND Digital has a number of resources to help if you want to make sure your organisation is compliant with best practice related to temporary access, including how-tos and detailed scripts for managing the process across multiple platforms. You can contact us at hello@and.digital.

The overriding take-away – which is more important than any particular method – is that it’s always possible to create safe, compliant and usable ways to run any aspect of your AWS infrastructure. Often, doing so means identifying not just the right tools but the appropriate part of the organisation to take ownership of a particular function. Building a task- and human-based approach, rather than just selecting tools by feature or ticking a box, will give you the best results.

Cloud

Related Posts