If you ever observed babies playing, you'll notice that at a certain point in their development, the idea of property comes into the game: "this is my toy, I'll not let you play with that". Usually parents needs to invest some time to make the baby understanding the value of sharing things: "the toy remains yours, but you can enjoy sharing it with other babies... If you are kind and polite the other babies may share in their turn their toys with you". Usually this trick work. The next step will be that they will start adding "special conditions": "you can use my blocks but only the blue ones" or " you can play with this doll but I'll not borrow you the pink dress". A different stories comes when sharing can make you save a lot of money: you do not need to buy the same toy your baby saw another baby is using if they can share it...
Did you ever try to apply this model to cloud computing?
I know it may sound strange at a first glance, but there are some similarities...
Let's start from the last example, kids sharing the same toys: doesn't it look like familiar to the idea of sharing the same master image? In a lot of cases I do not need my own master image, I can use the same one another user is using.
But the "conditions" apply: "you can use my same master image, but I do not want you to stay on my own network!" or "you can use my same master image, but you cannot use my package scripts!" ... Not a lot of differences from"you can play with my doll but I'll not give you the pink dress" or " you can play with my blocks but you can use only the blue ones"
There will be situations is which you even do not want to share the master image at all: "this is mine, it's my treasure, I have my own information there and I do not want you to see that"...I'm pretty sure you've seen babies doing that with their favorite teddy bear ;-)
I hope these few examples made you look at objects authorizations in a cloud with different eyes...
Anyway, the problem is there, a cloud is typically a shared environment and we do not want to have everybody to have access to everything. Privacy is important.
Let's see one of the ways to resolve this issue. We could give to every individual/user the right to determine who can access his own objects. "who" of course can be a single user or a group of users. Depending on the role of the user he can have access to different objects.
The cloud administrator for example can decide who can access a specific network, who can see a specific cloud group; the cloud catalog editor can decide who can access to which master image, or to which package scripts (package scripts are the building blocks for patterns); the image deployer can decide if somebody else can see the details of his images. In some cases he may also be interested in letting other users accessing his own volumes.
With the same ease a user can decide either to give full access, read-only access or no access at all to each of its own resources/objects.
Using such fine grained access policy makes the cloud software really flexible to fit various adoption models like a classical private cloud or a more complex environment like the ones a cloud service provider may have.
In case of enterprises and cloud service providers, authorization and network segregation are critical prerequisites for building and managing a secure cloud environment.
For this SmartCloud Provisioning is the right choice.
You can also rely on a robust auditing mechanism that allows you to track what is happening in the cloud: who logged in/out, user creation/deletion/update, data access attempts either if they are successful/unsuccessful, virtual machine instance creation/deletion update and far more...
If you are interested in walking through this model, you can have a look at what is included in IBM SmartCloud Provisioning beta code: