tmart
04-01-2009, 09:23 AM
This has come up in numerous contexts, but I wasn't sure if it was here on the forum... here are some ideas for you on a security model. Personally, I think that these are good features for any grid, but they are nearly critical for multi-tenant grids (eg. one grid shared by multiple administrative groups or departments). The bottom line I suppose is that it would be hugely beneficial to have a better administrative access/security model.
Here are some ideas for your consideration:
1) Role based security with perhaps something like the following administrative roles:
a) Can create, delete and manage users (sshkeys, passwords, roles, etc.)
b) Can administer applications and components (start, stop, restart)
c) Can ssh into running components (perhaps with a switch for with/without password confirmation)
d) Can obtain statistics and grid info
e) Can perform basic grid operations (reboot servers, disable servers, etc.)
f) Can perform basic volume maintenance (vol checks, repairs, etc. - but maybe not copies or resizing)
g) Can view all applications (individual app viewing would be covered in "2)" below)
h) Can configure all applications (individual app configuring and/or editing would be covered in "2)" below)
...
z) others beyond these examples
2) Application-specific grid access rights, perhaps/perhaps-not achieved using roles... for example, a user could be granted administrative access to a particular application -- and only to that particular application. Even viewing applications should be restricted. Whether or not applications are completely hidden other than the ones to which a given user has rights is another consideration. I think initially, it would be fine to use the *IX "ps" model where all users can see what processes (applications & components) are running, but cannot access those things without sufficient rights.
3) User quotas. In order to maintain a given application (starting app/components, provisioning, etc.), a user should have sufficient quotas privs for CPU/mem/bw. This would allow a superuser to create an application with a fixed quota for these resources and assign administrative access to only that application (per "2" above) to a particular user. Quotas could be assigned per-user or per-user/application. This thought needs more work - but what I'm asking for is a controlled mechanism to dish out resources.
4) Formal IP address assignment. Perhaps public IP addresses should be provisioned to applications somehow. It seems like this might be more difficult because there is no network layer intercepting the VIP activity on the external interfaces. But maybe you have some ideas here that could help?
5) Inability to "Login" through the GUI without confirmation of appropriate access. For example, to be able to "Login" to an application's running component with only the "View" role -- this is probably not a good thing.
6) Ability to (selectively) configure challenged logins from the CLI. While this can obviously be tightened via SSH configuration on running components, we don't really want to branch standard components solely to add this-- and we don't want to break the normal grid maintenance operations during component startup by changing accessibility of SSH on the components themselves. Perhaps a simple "please confirm password" would suffice on the CLI (or GUI) before the connection is even attempted. If this could be configured selectively, then it could probably be a user-specific or application-specific role.
Here are some ideas for your consideration:
1) Role based security with perhaps something like the following administrative roles:
a) Can create, delete and manage users (sshkeys, passwords, roles, etc.)
b) Can administer applications and components (start, stop, restart)
c) Can ssh into running components (perhaps with a switch for with/without password confirmation)
d) Can obtain statistics and grid info
e) Can perform basic grid operations (reboot servers, disable servers, etc.)
f) Can perform basic volume maintenance (vol checks, repairs, etc. - but maybe not copies or resizing)
g) Can view all applications (individual app viewing would be covered in "2)" below)
h) Can configure all applications (individual app configuring and/or editing would be covered in "2)" below)
...
z) others beyond these examples
2) Application-specific grid access rights, perhaps/perhaps-not achieved using roles... for example, a user could be granted administrative access to a particular application -- and only to that particular application. Even viewing applications should be restricted. Whether or not applications are completely hidden other than the ones to which a given user has rights is another consideration. I think initially, it would be fine to use the *IX "ps" model where all users can see what processes (applications & components) are running, but cannot access those things without sufficient rights.
3) User quotas. In order to maintain a given application (starting app/components, provisioning, etc.), a user should have sufficient quotas privs for CPU/mem/bw. This would allow a superuser to create an application with a fixed quota for these resources and assign administrative access to only that application (per "2" above) to a particular user. Quotas could be assigned per-user or per-user/application. This thought needs more work - but what I'm asking for is a controlled mechanism to dish out resources.
4) Formal IP address assignment. Perhaps public IP addresses should be provisioned to applications somehow. It seems like this might be more difficult because there is no network layer intercepting the VIP activity on the external interfaces. But maybe you have some ideas here that could help?
5) Inability to "Login" through the GUI without confirmation of appropriate access. For example, to be able to "Login" to an application's running component with only the "View" role -- this is probably not a good thing.
6) Ability to (selectively) configure challenged logins from the CLI. While this can obviously be tightened via SSH configuration on running components, we don't really want to branch standard components solely to add this-- and we don't want to break the normal grid maintenance operations during component startup by changing accessibility of SSH on the components themselves. Perhaps a simple "please confirm password" would suffice on the CLI (or GUI) before the connection is even attempted. If this could be configured selectively, then it could probably be a user-specific or application-specific role.