Understanding acls to harden KRS repository security

Support
1

I am trying to get a better understanding about acls to harden the repository to make sure it is in append only mode for all clients except for a particular admin in this example case admin@laptop responsible to manage the backups.

kopia server acl enable
kopia server acl list
#
# Define admin acls
#
kopia server acl add --user "admin@loptop" --access FULL --target type=policy
kopia server acl add --user "admin@loptop" --access FULL --target type=snapshot
kopia server acl add --user "admin@laptop" --access FULL --target type=user
kopia server acl add --user "admin@laptop" --access FULL --target type=acl
#
#
#
# Define user acls
#
kopia server acl delete --user "*@*" --access FULL target:type=policy,username=OWN_USER,hostname=OWN_HOST
kopia server acl delete --user "*@*" --access FULL target:type=snapshot,hostname=OWN_HOST,username=OWN_USER
kopia server acl delete --user "*@*" --access FULL target:type=user,username=OWN_USER@OWN_HOST
#
kopia server acl add --user "*@*" --access APPEND target:type=policy,username=OWN_USER,hostname=OWN_HOST
kopia server acl add --user "*@*" --access APPEND target:type=snapshot,hostname=OWN_HOST,username=OWN_USER
kopia server acl add --user "*@*" --access APPEND target:type=user,username=OWN_USER@OWN_HOST

  • Will gc run and gc run --full get affected when users do their own backups?

  • Any other way to harden

Thanks & really great progress in the project

SD

2

That looks about right,

I don’t think you need APPEND for type=user (that’s for creating new users) at all, and most likely nothing for “policy” once you define the initial policy set and/or global policies are enough.

One thing I’m not sure about is what’s going to happen in append-only mode at the end of a snapshot where retention policies are applied, the snapshot may either fail or keep accumulating manifests, neither of which are great.

What exactly is the goal here in preventing users from deleting policies and snapshots?

3

The goal is to start with a few users and host the repository in KRS.

Later assuming one system gets compromised and the attacker tries to delete backups from the KRS.

Basically the law of least privileges

Regards,
SD

4

Hi

What is content policy for?

user:*@* access:APPEND target:type=content
5

In my experimenting I found that at the end of a snapshot run it will error out with something like:

Error: unable to apply retention policy: error deleting manifest b2a27391a8008d76e994bed7dfff0f5b: access denied.

The snapshot run will fail to record a new snapshot.

@saviodsouza I did find that setting the retention policy to allow unlimited snapshots works just fine.

@jkowalski is it possible to handle the retention policy on the repository server side?

edit: formatting

6

I’m facing the same issue. Did anybody find a solution to have truly append-only backups?

It would be fine for me to add a cron job on the repository server side to run e.g. kopia snapshot expire, but unless the retention policy is practically unlimited, the snapshot creation fails with the same error message as the previous post.