Cloud Control Plane Users
A subject that seems to come up perennially is the people within an organisation that need to get access to the cloud providers "control plane" (the web console, and API).
Just for the sake of clarity, access to the control plane gives you the ability to view and modify/create infrastructure, to look at some of the runtime metrics of that infrastructure and to fiddle with the configuration and linkage between serverless components. Access can be limited to read-only, or read/write in certain areas or on certain services, but the main point is that it is for looking at infrastructure, not so much the things that run on it (although you can often get extensive access into data or other aspects of the running applications).
It's tempting to think that everyone who manages IT needs control plane access. Some common requirements we hear include:
- "Well, the networks folks might need to look into the way things are setup or are running, firewalls and so on..."
- "Our Windows admins might need to make changes to servers and whatnot"
- "The architects should have pretty broad access because they're responsible for the overall solution"
In many cases, these may be misunderstanding the roles of those groups and what the control plane actually is. Control plane access should always be considered a "privileged position", and not one to give granted "just in case"
Thinking about physical datacentres, in most cases very few people ever get to go there. Even fewer get to go in the actual machine rooms. Access is strictly on a needs basis, is usually time-limited and often needs several approvals and whatnot. Some of that approach usually makes sense for cloud control planes too.
You're hopefully building your infrastructure with code (using something like Terraform, perhaps). That code is probably owned and modified by a devops team, and should be "the source of truth" for your infrastructure. With that in mind then, there shouldn't be much facility to make manual changes using the web console (any such changes need to be marked as "ignore changes" in the code, or else the code will probably revert the manual changes). Once you realise that manual changes are not possible, or are extremely limited then often the justification for control plane access dissipates.
Where you think someone needs read/write access, it's also worth thinking about how well qualified those people are to make changes in the cloud provider. That is, your devops team probably works in the cloud every day and are experts at it, they keep up to date with new features and know that if you touch "X", then it affects "Y" and "Z" too. How about the occasional users? Are they keeping abreast of cloud changes and inter-dependencies? How well do they even understand your architecture, let alone any cloud nuances? If they make a change are they going to be able to predict the actual effects of it? If not, then they should probably have read-only access and call the devops folks for anything else.
Read-only access might sound "safe", but even that isn't really true. In most cases it'll give a great deal of access to very confidential (and in some case controlled) information. It's of course possible to restrict access to some specific areas to avoid this problem, but now you've got a tricky task of trying to give enough access without giving too much.
It turns out read-only access is a lot less interesting than read/write (restricted read-only even more so!). In fact, it's so uninteresting that it's quite possible you'll go ahead and create accounts for whole teams of people only to find that only one of two of them ever bother to log on and look around. Most of them will have figured out that if they want anything doing, they just call up the devops team and have them do it for them. All those unused accounts are a security risk, and if you're doing security properly you'll close them in due course.
There are of course exceptions to every rule, and the more serverless your cloud environments are, the less traditional "systems management" makes sense, and the more control plane access helps out (mainly because its where logs and metrics end up). Of course in such situations you may need more people with control plane access - but probably read-only, or very close to it in most cases. You should also be able to limit that access to just the logs and metrics rather than over the whole estate.
So in short... there's no point creating user accounts just to close them again. Scrutinising your requirements for control plane users will probably save you a lot of work. Sometimes this requires some hard challenges to different groups in an organisation, which can be tricky for devops teams to achieve unless their Security teams can help out.
Pre-Emptive can help with untangling your requirements, cloud design, security and cloud implementations. Contact us to see how we can help you.