So right now, SSHD and HTTP are not access zone aware, they'll only answer in the system access zone. Same for VSFTPD. You can for the time being use this to your advantage [I say for the time being because I can never predict the future, my crystal ball is in the shop ]. Don't try and segregate what interfaces or IPs can/will answer to apache or sshd because this is both difficult and unsupported, instead, put all user data in a non-system access zone. Join the cluster to AD, and in that new access zone, let the AD provider and the local auth provider for that access zone be the only valid auth sources. In the system access zone you'd still have AD, local:system and file:system, so root/admin/etc will still work. Yes use RBAC by tying your AD group for storage admins into a role either a default role or a custom role.
In general it's important to understand that all Isilon management is done in-band, there is no control station / data mover type of out-of-band segregation or management. For many administrators of Scale-up architectures this is of course a pretty radical change.
If SSH and HTTP(S) won't be access zone aware in future everything is fine. That's ok for me at the moment.
But what do you mean with "put all user data in a non-system access zone"? The SMB shares and NFS exports?
Or should I create different root folders for both zones as e.g. /ifs/data/user and /ifs/data/admin? I think that's not necessary because the system zone will only be used for administration purposes. There are no different departements as described in many EMC examples about access zones.
The FTP service is not zone aware too and only works at the system zone? So if a client want to do a FTP transfer it must use the IP subnet of the System zone?
Why would you leave the local file provider active at the new user access zone? I do not see any reason for that because all users connections will be initiated by AD users/groups.
when you say HTTPD is only available in System does that mean i am also only allowed to do API-Calls in the System-Zone? In that case when deleting Folder-Structures via API i recognized the necessity of having Filesystem-Permissions on that specific structure to delete it. This would mean i have to add all Authentication Providers of the Accesszones to System to be able to delete Folderstructures via RestAPI. is that correct? Or is the RestAPI available in the specific accesszones?
You're absolutely right, while the platform API certainly can take commands related to access zones, like: create share1 in access zone3, it cannot answer those calls on IPs in any access zone except for system at present. If this feature is of value to you, please tell your account team to submit a feature request for it.
By put all data in a non-system access zone, i mean just that; create an extra access zone on the cluster. So use the structure /ifs/clustername/accesszonename as your root base path, put all data under that path, and therefore all shares and exports likewise pointing at the data under that path. Because an access zone will need a unique smart connect zone name, that's all your users will have to know how to access the cluster, and that name will not answer to SSHD, HTTPD, VSFTPD, etc. So you've achieved your desired results purely because those services are not access zone aware.
As to the AD provider and local auth provider in the new access zone, the act of creating a new access zone creates a new local auth provider for that access zone. Think of it in terms of a windows server. Each and every windows server has it's own local administrators group, backup operators group, and so-forth. Now you don't have to use those groups in file permissions, and I would strongly advise against doing so, but the groups do exist all the same, even though their memberships will all be empty. Again, not at all unlike a windows file server.
i was talking about namespace API but i guess the same applies?
from my point of view it is good to have API and SSH only available in systemzone. But then automation of foldercreation (including ACLs) for the different accesszones gets quite difficul if you don't have any trusts to the authentication providers of the accesszones.
But the cluster is already filled with more than 500TB an important data which have to be moved to an other folder than.
What is there against using the /ifs/ as the Zone Base Directory for both access zones? There will never be created another access zone than the existing system and the new user access zone.
crklosterman
450 Posts
0
January 27th, 2016 08:00
Phil,
So right now, SSHD and HTTP are not access zone aware, they'll only answer in the system access zone. Same for VSFTPD. You can for the time being use this to your advantage [I say for the time being because I can never predict the future, my crystal ball is in the shop
]. Don't try and segregate what interfaces or IPs can/will answer to apache or sshd because this is both difficult and unsupported, instead, put all user data in a non-system access zone. Join the cluster to AD, and in that new access zone, let the AD provider and the local auth provider for that access zone be the only valid auth sources. In the system access zone you'd still have AD, local:system and file:system, so root/admin/etc will still work. Yes use RBAC by tying your AD group for storage admins into a role either a default role or a custom role.
In general it's important to understand that all Isilon management is done in-band, there is no control station / data mover type of out-of-band segregation or management. For many administrators of Scale-up architectures this is of course a pretty radical change.
Hope this method helps,
~Chris Klosterman
Advisory Solution Architect
EMC Enablement Team
chris.klosterman@emc.com
philippspohr
1 Rookie
•
107 Posts
0
January 28th, 2016 02:00
Hi Chris, thanks for your answer.
If SSH and HTTP(S) won't be access zone aware in future everything is fine. That's ok for me at the moment.
But what do you mean with "put all user data in a non-system access zone"? The SMB shares and NFS exports?
Or should I create different root folders for both zones as e.g. /ifs/data/user and /ifs/data/admin? I think that's not necessary because the system zone will only be used for administration purposes. There are no different departements as described in many EMC examples about access zones.
The FTP service is not zone aware too and only works at the system zone? So if a client want to do a FTP transfer it must use the IP subnet of the System zone?
Why would you leave the local file provider active at the new user access zone? I do not see any reason for that because all users connections will be initiated by AD users/groups.
sluetze
2 Intern
•
300 Posts
0
January 28th, 2016 03:00
Chris,
one additional question:
when you say HTTPD is only available in System does that mean i am also only allowed to do API-Calls in the System-Zone? In that case when deleting Folder-Structures via API i recognized the necessity of having Filesystem-Permissions on that specific structure to delete it. This would mean i have to add all Authentication Providers of the Accesszones to System to be able to delete Folderstructures via RestAPI. is that correct? Or is the RestAPI available in the specific accesszones?
Regards
--sluetze
crklosterman
450 Posts
0
January 28th, 2016 07:00
Sluetze,
You're absolutely right, while the platform API certainly can take commands related to access zones, like: create share1 in access zone3, it cannot answer those calls on IPs in any access zone except for system at present. If this feature is of value to you, please tell your account team to submit a feature request for it.
~Chris
crklosterman
450 Posts
0
January 28th, 2016 07:00
Phil,
By put all data in a non-system access zone, i mean just that; create an extra access zone on the cluster. So use the structure /ifs/clustername/accesszonename as your root base path, put all data under that path, and therefore all shares and exports likewise pointing at the data under that path. Because an access zone will need a unique smart connect zone name, that's all your users will have to know how to access the cluster, and that name will not answer to SSHD, HTTPD, VSFTPD, etc. So you've achieved your desired results purely because those services are not access zone aware.
As to the AD provider and local auth provider in the new access zone, the act of creating a new access zone creates a new local auth provider for that access zone. Think of it in terms of a windows server. Each and every windows server has it's own local administrators group, backup operators group, and so-forth. Now you don't have to use those groups in file permissions, and I would strongly advise against doing so, but the groups do exist all the same, even though their memberships will all be empty. Again, not at all unlike a windows file server.
~Chris.
sluetze
2 Intern
•
300 Posts
0
January 28th, 2016 07:00
Hi Chris,
i was talking about namespace API but i guess the same applies?
from my point of view it is good to have API and SSH only available in systemzone. But then automation of foldercreation (including ACLs) for the different accesszones gets quite difficul if you don't have any trusts to the authentication providers of the accesszones.
Rgds
sluetze
philippspohr
1 Rookie
•
107 Posts
0
January 28th, 2016 08:00
Ok, now I understand what you mean.
But the cluster is already filled with more than 500TB an important data which have to be moved to an other folder than.
What is there against using the /ifs/ as the Zone Base Directory for both access zones? There will never be created another access zone than the existing system and the new user access zone.