September 24, 2012 | Written by: Rossella De Gaetano
Share this post:
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 it.”
Usually parents need to invest some time to make the baby understand 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 their toys with you”. Usually this trick works.
Next, they will start adding special conditions: “You can use my blocks but only the blue ones” or “you can play with this doll but not borrow the pink dress.” It’s a different story when sharing can help you save a lot of money; for example, you do not need to buy the same toy as the other baby if they can share it.
Did you ever try to apply this model to cloud computing? I know it might sound strange at a first glance, but there are some similarities.
Let’s start at the last example of kids sharing the same toys: isn’t the idea of sharing toys similar to sharing the same master image? In many cases, I do not need my own master image, I can use the same one another user is using.
But the “special 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 the toy-sharing conditions.
There will be situations in which you 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 quite sure you’ve seen babies doing that with their favorite teddy bear 😉
I hope these few examples helped you look at object authorizations in a cloud, with different eyes.
Anyway, the problem is there; a cloud is typically a shared environment and we do not want everyone to have access to everything. Privacy is important.
Let’s examine one of the ways to resolve this issue. We could give each user the right to determine who can access that user’s own objects. “Who” of course can be a single user or a group of users. Depending on the role of the user, that user can have access to different objects.
The cloud administrator for example can decide who can access a specific network, and who can see a specific cloud group; the cloud catalog editor can decide who can access which master image or which package scripts (package scripts are the building blocks for patterns); the image deployer can decide who can see the details of his images. In some cases, the image deployer might also be interested in letting other users access the deployer’s 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 the user’s own resources and objects.
Using such a fine-grained access policy makes the cloud software really flexible to fit various adoption models, such as a classical private cloud, or a more complex environment, such as those that a cloud service provider might have.
In the case of enterprises and cloud service providers, authorization and network segregation are critical prerequisites for building and managing a secure cloud environment. For this prerequisite, IBM SmartCloud Provisioning is the right choice.
You can also rely on a robust auditing mechanism so that you can track what is happening in the cloud: who logged in and logged out; user creation, deletion, updates; data access attempts and whether they are successful or unsuccessful; virtual machine instance creation, deletion, updates and far more.
If you are interested in “walking through” this model, see what is included in the IBM SmartCloud Provisioning beta code:
- Customer interaction program
- Cloud Provisioning and Orchestration – Development Collaboration Community