NextCloud with Wasabi S3 (Part2)

This post is the second part of the previous, the most read one on our blog. After the technical introduction on how to deploy NextCloud using the containerization approach made in Part1, we explained basic functionalities of Wasabi S3, to show in this post, how to glue it all together to get functional and reliable cloud private file-sharing services.

For those who just look for an easy way of using NextCloud services, I would recommend buying ready-to-use offers from many more or less reliable providers giving more or less (usually very little to be honest) customizable functionalities. So if you want to take a shortcut then look here. Also, if you just want to install NextCloud on your VPS in the easiest way possible just to try it out – this post is also not for you, but you will certainly find many others. This post, however, is for those who want to use NextCloud as their basic file sharing system for the needs of commercial activity, which depends on the availability of company data, the possibility of easy professional cooperation, and so everything that increases efficiency affecting the satisfaction of the final customer 😉 Even now, when I’m writing this post, I use a disk connected to NextCloud, which replicates the file with this post to the Wasabi S3.

When we started the NextCloud implementation at NubiSoft we approached it without much thought and we naturally created accounts in NextCloud for each team member and additionally one bucket in Wasabi storage for each of them. In this way, everyone had their NextCloud directory on the local computer (or several of their computers) in which one of the sub-directories was mapped onto a bucket in Wasabi. Every team member had configured it by itself using its own Wasabi API key. And it started a real Armageddon! – Everyone in the company responsible for some area shared on their own some files, in their opinion worth sharing, with others. This led to a lack of control over the structure of the company’s resources, their location, and the management of their availability. After a month, terrified by the growing mess, we backed up all important resources in one place and turned off our NextCloud server to calmly think about what mistakes we made and how to avoid them on the next attempt.

This time, we assumed that the most important thing is security and order in the structure of our electronic company resources, and since they are deposited in Wasabi at the end, the primary goal is to maintain order there. NextCloud (or it could be OwnCloud or something else) is just a platform that provides an interface to our PCs. Our thoughts are illustrated in the implementation diagram below.

We will now show you how to configure the entire system for sharing resources within one group of common interests (on the basis of this, of course, you can create many different groups – e.g. separate for production dept, sales dept, etc.). First, you need to create a secondary account in Wasabi that will not be a root account – this is dictated by security reasons. Then create a bucket or even two as in our case – one will be for everyday files, which are often subject to editing or deleting, and the other for important resources, whose changes will be stored with accuracy to each version and even in the case of logical deletion, it will still be possible access to them. Importantly, for security reasons, the previously created user will be restricted to only the two previously mentioned buckets and the policy mechanism is used for this purpose.

{
  "Version": "2019-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::next.corpo",
        "arn:aws:s3:::next.corpo/*",
        "arn:aws:s3:::next.dev",
        "arn:aws:s3:::next.dev/*"
      ]
    }
  ]
}

All that’s left is to set up retention policies in line with our requirements. In our case, we left default values for the dev bucket and event versioning and logging enabled for the corpo bucket. After that, we only generate the API key and we have finished playing at Wasabi.

In NextCloud, for one user who is the head of a given interest group, we configure two external storages.

.. and in the folder view, we have to share these two external storages with a group of interest (defined as a group in NextCloud).

From now on, each member of the group sees (on their PC) two shared folders that are replicated between their computers and additionally stored in a cheap, reliable and secure place at Wasabi Systems.

That is all. And you? What techniques do you use to share and secure your company resources with the team?

Another view angles

1. You may ask why we use Wasabi versioning for the corpo bucket since NextCloud also implements versioning? Well, versioning in NextCloud, because it is implemented on local resources (i.e. in our case VPS) is volatile and therefore we do not trust him too much. VPS itself has an availability of 99.95% which is a much smaller indicator than Wasabi Cloud.
2. Does the above mean that NextCloud versioning is not useful for us? Nor! Once a perplexed teammate asked me if I would be able to recover a file that he accidentally overwrote, and it wasn’t a file from the versioned corpo directory, but from the ‘plain’ dev directory. I told him to recover the file using the NextCloud web client – the NextCloud platform is great in this respect – it manages the number of stored versions itself depending on the free disk space. Although our VPS is not very big, thanks to NextCloud we can recover versions of all files even a dozen or so days ago.
3. You could ask how stable our NextCloud implementation is and do we have any problems with it? Absolutely none! Look at the picture below!

•