Background
A client recently wanted to move several DevOps and scanning tools into the cloud, to which they were in the process of proving out and transitioning.
We had a number of security scanning and static analysis tools, along with corresponding dashboards and a continuous integration server to orchestrate them. All of these tools were dependent on manually-configured, bare-metal servers, presenting a serious risk if anything were to happen to the servers or environment. Further complicating matters was the highly-coupled nature of these tools—they rely on artifacts of other tools lingering in the local filesystem, and steps of the process happening in an arbitrary but rigid order.
Goals
Docker and Kubernetes, through the AWS-native Elastic Kubernetes Service (EKS), was our choice of services to try to port our tools onto. With this as our goal, we set out provisioning resources in a relatively untested, untamed cloud.
Challenges
The way permissions were sliced up, access was provided to AWS through federation.
For the purposes of this post, federation is defined as a system in which users’ identities across numerous, separate systems are linked, and frequently involves the use of single sign-on (SSO).
Unless administrative privileges are liberally distributed, federated identity management requires the existence of higher-permissioned roles for users or automation to assume when performing administrative actions. Our users had extremely limited permissions, and other roles could not be assumed. Service accounts and corresponding tokens were also not available due to this federated access model—all accounts had to be tied directly to human users.
Federation also lends itself to, though does not necessitate, more old-fashioned, centralized organization of user permissions. In my most recent experience, a human user’s access started and stopped with AWS console access (and even then, only to a heavily curated amount of information). Resources, provisioned through the service catalog, came with their own roles they would run as. The consequence of this is that there is no role that can be used to launch these resources programmatically, using templates alongside the command line.
Enterprises are likely to hand out federated roles in an automated, one-size-fits-all fashion to every new user, in conjunction with their email, internal ID, and access to numerous other systems. Many of these users will never log in to the cloud, and the principle of least permission is taken to new extremes: users don’t have the permissions they need to use the cloud effectively, and they’ll have to fight tooth and nail to expand on these. Federation is easily misused to institute rigid, generic roles for all users that are difficult or impossible to change due to policy and infrastructure. This flies in the face of DevOps practices of breaking down communication barriers between developers and operations.
To that end, endeavoring to plan these generic permissions comprehensively, before testing or even using any of the systems they’re designed to work with is doomed to fail. There is no way to know all future scenarios a user will face, and what they could need to face those scenarios; trying to construct this upfront, deliberating and arguing over which permissions are reasonable for a generic user, and which aren’t only serves to more deeply enshrine these educated guesses as perfect, future-proof solutions. Federation encourages central, one-time planning of systems and the permissions within, and discourages adaptability.
Conclusion
With enough layers of bureaucracy, any new, powerful tool can be stripped down to the point of no longer surpassing or even meeting the functionality of what it’s replacing. Federation provides an excellent knife to whittle away all of the benefits of the cloud.
NIST defines cloud computing as being characterized by broad network access and on-demand self-service (more on this to come). In particular, NIST states that resources should be able to be provisioned “as needed automatically without requiring human interaction with each service provider”. Federation encourages the opposite of this: generic, permission-less roles for all, and a drudge through countless human stopgates in order to provision anything.
