My wishlist for a Snap Creator cloud backup solution

[filipsneppe]

Hi,

We are deploying a "cloud" backup solution where primary/source storage systems (at customer locations) and destination storage systems (at our datacenter) are all NetApp-based storage.

We intend to use Snap Creator (official version 4.1.0) as the central scheduling & configuration tool.

Our basic setup is to create one profile per customer and store the various backup configurations for that customer under his profile.

Via RBAC we create one or more accounts for the customer with different roles depending on the types of operations the customer should be able to perform.

The RBAC capabilities of Snap Creator is one of the main reason we intend to use SC as the central scheduling and configuration tool.

I'd like to share with you some experiences and questions I am encountering.

(1) use of global.conf

Initially we were thinking of this scenario:

- put our (destination) filers' credentials in the top-level global.conf file

- put the customer filers' credentials in the global.conf file under his profile directory

When using the GUI to create a configuration, I was hoping that SC would merge both global confs and provide an easy way to store all filers' credentials.

It  appears SC is simply using the profile global.conf over the general global.conf.

Is there any way to achieve this merging of filer credentials from both global.conf files ?

(note that this has become irrelevant in our setup since we are now using vfilers at the destination and using the vfiler credentials for that customer's destination vfiler in his global.conf)

(2) TRANSPORT=HTTP or HTTPS versus individual filers with a different configuration

There's a possibility to use either HTTP or HTTPS to connect to the storage systems, but there doesn't seem to be a way to overrule this on a per-filer or per-vfiler basis.

Since we are using vfilers at the destination, we cannot use HTTPS. But this also means that SC access to the source filers has to be over HTTP, which is a security concern for certain customers.

A way to override the default TRANSPORT option per-filer would be nice.

Or am I overlooking something ?

(3) RBAC roles

Where can I find more information about the "CUSTOM" RBAC permission that can be assigned to a role ?

(4) Limiting the possibility to download global.conf

Given a customer with a role with the following permissions: VIEWER, BACKUP, RESTORE, CONFIGURATION, SCHEDULER, I can log in with this user, go to "Management" -> "Global Configurations" and then download the global.conf. Given our specific setup, the customer can now set up his own SC server and, by copy-pasting the destination credentials into a new configuration, get access to a lot of data from volumes he shoul not have any access to.

What would be a setup that does not allow this ?

Essentially, what we are testing out in our setup is ways to give customers some flexibility by offering them the possibility to create/manage their own backups, but we're hitting some practical problems and security risks we'd like to solve. As a tool where we are setting up backups using SC and a customer only has read-only access, it performs great!

Best regards,

Filip

[ktenzer · Accepted solution]

Hi Filip,

First thanks for posting and bringing light to a very important topic.

(1) use of global.conf

Is there any way to achieve this merging of filer credentials from both global.conf files?

Your observation is correct, let me explain more.

There are three types of configs (as you know) the global, profile global, and config itself. The configs use a downstream inheritance model which is global->profile global->config. If a parameter exists twice then the one downstream takes precedence. This means the config itself has ultimate overwrite if you will. If a global and or profile global is used they are actually merged in memory. Given all three we would read global->profile global->config and of course any duplicate parameters would be overwritten as the next config is read.

Assuming the same parameter it would be written over and not merged. This is a great idea for a feature. Certainly we have also talked about an upstream inheritance as well, or even allowing enforcement of parameters from global or profile global.

In Snap Creator 4.2 (will be out in summer 2014) I am happy to report we will have a credential store and no longer will credentials be in configs, they will be central and tied to RBAC. This would solve your problem I feel.

For now you have situation where admin wants to add storage credentials for secondary and tenant for primary. My recommendation is dont use global but rather profile global. This means you would add secondary to profile global. Customer can then add primary. I realise this isnt ideal and a pain for the admin but I think this is best solution until 4.2 is out.

(2) TRANSPORT=HTTP or HTTPS versus individual filers with a different configuration

Where you on our developer calls for SC 4.2? I am joking but we talked about this. As part of new credential store in SC 4.2 you will be able to set port on controller basis so you can have different ports. Today you can only use one port per config I am afraid.

(3) RBAC roles

Where can I find more information about the "CUSTOM" RBAC permission that can be assigned to a role ?

Our documentation should be improved hopefully soon. I will talk to our TME John Spinks to put together something comprehensive. To get you going RBAC in SC seems simple on surface but is quite powerful and we have much bigger plans for this moving forward.

Basically you have a user, a user you assign a role, a role you assign a permission, and a permission you assign an operation. I think you can only assign operations to permissions in CLI (but could be wrong).

You can create a custom permission basically and then add whatever operations you want. In addition you can then add your customer permission as well as the built in ones to a user. In this sense you can get very custom and detailed but most customers just use the built-in capabilities however for cloud use cases this is obviously not enough.

Let me know if this is enough to get you going? I can give examples as well if you need.

Another important thing to understand is how a user ties to RBAC and a profile. You assign a user a role or roles but also profile or profiles. A role allows user to do things and a profile allows them to see things is the way to think about this. Once we have credential store you will be able to tie controllers to users as well and we have plans to add many more components...this is just the beginning. Please share your thoughts and ideas we need them?

(4) Limiting the possibility to download global.conf

You need to create I think custom permission for this.

If you run this CLI command you can see all the operations

./snapcreator --user <user> --passwd <passwd> --action opList --verbose

There are two permissions which control this, globalRead and globalWrite. You would need to make sure that user didnt have either of those. Now I am not sure if you remove those if user then cant access profileGlobal. We havent broken out operations for profileGlobal so this might be something we need to do. I have to run for the day but I will test this tomorrow. In meantime you can as well and let me know.

Hope this helps

Keith

[filipsneppe]

Hi Keith,

Thanks for this extensive reply. It answers pretty much all my questions. So I hope that with the credential store coming in SC 4.2, that you will take into account the cloud scenario I described.

There is maybe one more thing I can add to this wishlist: Ideally, we want to have a setup with two SC servers, one active and one standby. One way to make it easier to manage two SC servers is a way to export job schedules and (re)import them on another server. This would also be useful in upgrade scenarios I guess.

Best regards,

Filip