Current Backup Security Violates Least Privilege

Issues Dgraph
, ,
1

Experience Report for Feature Request

In Dgraph v20.03.4 and v20.07.0, backups require essentially root access (i.e. guardians group) to trigger backup. This requires exposing the keys to be able to handle operational lifecycles like backups. Thus to have business continuity (disaster recovery, risk mitigation), users must compromise their security and increase their attack surface to facilitate backups.

What you wanted to do

I would like there to be a new group backups whose membership will allow backup operations to be performed, and not have other unnecessary administrative privileges. This way, a user with backups membership would not be able to delete users or grant other users membership guardians

What you actually did

Really, there is nothing that can be done to mitigate the risks of having admin credentials used stored on a system that schedules the backups.

Users can use extraordinary measures, such as sealing them in Hashicorp Vault infrastructure, but the risk of elevated admin credentials is still there.

Why that wasn’t great, with examples

The risk to have unnecessary administrative privileges to automate backups cannot be avoided.

Any external references to support your case

This is well-known security principal and required for audits in the industry.

For example, on Linux, ssh is often configured to prevent root login, because it is that dangerous.

Similarly, many systems, such as Microsoft Active Directory and Windows Server, have a backup operators group that allows members to do backups but does not have other unnecessary administrative privileges (ref. link).

Oracle Database has a SYSBACKUP user (ref link) different from SYSDBA that has limited privileges necessary to do backups.

3

@gja: you had mentioned issues with acl and backup on Slash. Do you have a proposal or a ticket on handling it? Considering if we can address both the issues when we work on updating how permissions work with backup.

4

No. Rather, this is the issue that prevents me from adding ACLs on Slash (backups stop working if ACLs are enabled, unless you keep the groot password somewhere)

I think @joaquin is suggesting creating a backups group which can read all predicates, but not have access to write or modify things, which could make sense for most enterprise scenarios, but I’ll still have a few hoops to jump through for Slash (like storing the passwords, which I’m really reluctant to do).

5

@vvbalaji Essentially @gja correct. As an example:

In Dgraph Helm Chart, users have to increase their attack surface, and thus compromise their security, by specifying the groot password (or another user in guardians group):

This is so when doing a post with GraphQL (or REST) to get an accessJWT to do the backups:

If there was a backups group, this would mitigate risk, because if the secret was compromised, the secret would not provide full access where the attacker could do a lot of damage. I think this would work for both OPD enterprise and Slash solutions.