storeacl for SnapCreator

[magnus_nyvall]

For SnapDrive this tool exists to limit access for Snapdrive to a filer.

http://now.netapp.com/NOW/download/tools/storeacl/

Any chance of something similar for Snapcreator and NFS?

Regards Magnus

[ktenzer]

I will look into this.

We wouldn¹t create our own but use this tool, so need to figure out how it

works. Maybe SC can use it today? It doesn¹t seem to be tied into SDW since

it is a separate tool.

Keith

[magnus_nyvall]

I am looking at this because we have concerns about security with SnapCreator.

Our problem is basically that SC must run as root on our SAP/DB2 systems and we do not want the sysadmins/customers with root access to be able to do bad stuff on the Storage system.

We can see security issues with giving SC admin user in filers to much rights since non-storage personnel can edit snapcreators configuration files on the DB server.

You could say we are an internal  "Service Provider" in a large organization that sells Netapp NFS storage with snapshot backup to servers that we our selfs do not control and we do not want our customers to be able to "fiddle" with the storage configurations.

An example is making a flexclone and have it exported somewhere bad via SC.

Currently this is not much of an issue since each "SAP customer" are in its own vfiler.

But we have plans of making a DB2 hotell server in the future where several customers might exist in same vfiler.

A similar solution that Snapdrive and storacl could be a solution.

Basically storacl creates an xml file in /etc on the netapp filer and snapdrive reads this file if it exists and imposes security restrictions from that file

Do you have any Best Practice recommendations around security and SC?

(I am guessing you will say that we should not let people have root access.)

Regards Magnus

[ktenzer]

Snap Creator does not have to run as root, it can run as either root or in case of DB2, the DB2 user.

In addition with the scServer/scAgent you have the ability to further add security, since the scServer communicates with storage and the scAgent DB2.

The SC 3.5 GUI could also help since it offers RBAC (note CLI offers no RBAC just GUI, but you could limit folks to no CLI access), however when SC communicates to storage it require a username/password and this would have certain permissions which apply to all resources, you cant limit user to aggregate or volume like storeacl.

Another thing is DFM proxy. SC doesn't even need to talk to NetApp storage you can do everything through a DFM proxy using the DFM user, and communications go through it, this could also be an option. This is also in 3.5.

I think there are a lot of things that you can explore

As for Best Practices for security, I would recommend following:

1. Dont give folks root access to anything, OS or Storage

2. Use vFiler as you are doing

3. Use the DFM proxy, and manage security through it, you have more flexibility and it is more secure than creating data ontap users

4. For shared SC environments, use SC 3.5 and RBAC within SC so that users can work in their own space.

5. Use scServer and scAgent

6. Use global configuration files. This allows you to define ONTAP or DFM users and users of SC must re-use that info. They never get an ONTAP or DFM user/password or see password, they simply import a global config or they cant do anything.

Here was a video done maybe 4-5 months ago on some of the 3.5 features, like RBAC and DFM proxy which could help:

https://communities.netapp.com/videos/1999

I have opened a request to research this and see if we can do what storeacl did, but I have no commitment yet from engineering on when / how that could be done.

Regards,

Keith