When you are developing software in a large organisation—there will be more than one developer (more likely hundreds), there will be more than one project (tens to hundreds), and multiple lines of business.
You will want to ensure that only those people with a need to access environments can do so. Conversely, you will want to ensure that developers who need access to environments can get access quickly and easily—with a minimum of fuss.
You will need a way to organise all of your development efforts, to implement quotas where required, to segment environments into development, test, production and the like. You will need it to be quick, easy, visible and flexible.
With Orgs and Spaces in Pivotal CF—you can achieve just that. In addition, role-based access control (RBAC) ensures that users access just the resources that they need—and no more.
In this episode, we take a quick look at how Orgs and Spaces work in Pivotal CF and the kinds of role-based access you can implement.
PLAY EPISODE #17
- Subscribe to this feed.
- Find more episodes of All Things Pivotal podcast.
- Feedback: email@example.com
- Links Referred to in the Show:
Welcome to the All Things Pivotal podcast, the podcast of the intersection of agile, cloud, big data. Stay tuned for regular updates, technical deep dives, architectural discussions, and interviews. Please share your feedback with us by e-mailing firstname.lastname@example.org.
Hello, everyone, and welcome back to the All Things Pivotal podcast. My name’s Simon Elisha, and I’m really glad you could join me today for what will be a short, but hopefully perfectly formed little podcast today.
What we’re going to speak about today is organizations, spaces, roles, and permissions within the context of pivotal cloud foundry, particularly, and cloud foundry in general. So, these are topics and concepts you’ll hear mentioned in passing in things that are very relevant to how you deploy pivotal cloud foundry into your environment, so I thought it was worth spending a little bit of time just explaining what they are.
Let’s firstly look at orgs and spaces. An organization, or an org, is a set of users grouped together for management purposes, and all members of an org share the same resource quota plan, services availability, and their custom domain. We’ll talk about that shortly, but, in an nutshell, organizations allow you to create a multi-tenant environment within your pivotal cloud foundry deployment.
Organizations can be defined any way that you like. Typically, they’re defined around things like line of businesses, or particular projects, or a specific division, or an initiative. There’s no sort of right way to do it. There’s the way that suits your organization, is really the way to do it. You don’t want to overdo the orgs, but orgs give you a level of abstraction that enables you to define who can do what in a particular environment.
Associated with these orgs are quota plans, and a quota will apply to all the activities within their particular organization, and in particular they provide limits and tracking around memory use, so memory’s memory that is used by application instances; the services the consume, so how many services you can allocate to applications within that environment; and the number of routes, or ‘roots’, depending on where you come from, to applications that are allowed to be configured. These are custom or multiple domains that can be configured so you can control limits on all of those.
Within each organization, you can have multiple spaces. Each org will have at least one space, you have to have one, and every application and service is scoped to a space. Spaces are a very important additional level of abstraction for organizing applications and services. A space gives you access to a shared location for application development, deployment, and maintenance, and users will have specific space-related roles.
What do we normally organize our spaces into? The kind of canonical version is really having a development space, a test space, a staging space, and a production space. That’s one example. It’s not the only example, but it shows you how you can move an application through different spaces based upon your development pipeline, and have different roles and responsibilities allocated to that space, and different things happening in those particular spaces.
In the development space, there might be a lot of experimentation going on, and lots and lots of instances being spun up and spun down, whereas your staging space may be far more static in terms of what’s going on there, there’s only really candidate code that’s going, flying through that particular environment at any one time.
We have the concept within pivotal cloud foundry of users, and those users have roles and permissions, so this is role-based access control, and you can have roles and permissions for orgs and for spaces.
I want to go through what they look like. From an org perspective, you can have an org manager, and the org manager is pretty powerful, as you’d imagine. The org manager can add and manage users, can view users and edit the over-alls, can view the org quota, can create, view, edit, and delete the spaces themselves, and can invite and manage the users in spaces, and can view the status, number of instances, service binding, and resource use of each application in every space in the org, and they can also add domains to the org.
The org manager is kind of an important role. There would not be many org managers, but they would do quite a lot of stuff, in terms of the general setup, etc.
The other org-related role is the org auditor, and this is useful for people who need to view but not edit information around the org, so they can view users in over-alls, and they can view the quota. Again, this is more of an operations-type function, or a management-type function to see what’s going on. They’re the roles you have for the org.
In the space world … Again, it scopes down within the org, each user can have access to one or more spaces … There is the space manager, and the space manager can add and manage the users in this space, and can view the status, number of instances, service bindings, and resource use of each application in this space. Again, this space manager would probably be the same type of person who would be a, uh, an org manager, or it may be a delegated function.
If you’ve got a lot of change happening in that particular space all the time, lots of users coming and going, maybe the org manager doesn’t want to be managing that all the time, so they delegated to someone who’s a space manager.
The most common role, though, is the space developer, and a space developer can deploy an application, start or stop an application, re-name an application, delete an application, create, view, edit, and delete services in a space, bind or unbind a service to an application; they can rename a space, they cane view the status, number of instances, service bindings and resource use of each application in the space; they can change the number of instances, the memory allocation and disk limit of each application in the space, and they can associate an internal or external URL with the application.
This is the most common role that you’ll be providing your space users, because, hopefully, most of your time is spent helping developers do what they do best, which is develop, hopefully, cool code that works well.
The final role is that of space auditor, and again, this is the ‘view only’ role, where they can view the status, number of instances, service bindings, and resource use of each application in that particular space.
So, a neat and efficient way to divide up who has access to what: again, orgs at the high level to have, so that macro and coarse level of dividing of the organization up, in terms of structure, and in spaces for more fine-grain control within those particular organizations.
A user can have, obviously, access to more than one org, and can have access to more than one space, and can have different roles and responsibilities within those orgs and spaces as you see fit; and of course, you can change them whenever you need to.
Just a short, quick one today, but an important one. Orgs and spaces, and role-based access control within those. They’re very important, they’re a big part of Pivotal CF, and something to keep in mind.
Until then, please do let others know that the podcast exists, and let us know your suggestions and ideas. You can reach us email@example.com, and we do like to get your feedback, and we respond to every bit of feedback we get.
Until next time, keep on building.
Thanks for listening to All Things Pivotal Podcast. If you enjoyed it, please share it with others. We love hearing your feedback, so please send any comments or suggestions to firstname.lastname@example.org.
About the Author
Simon Elisha is CTO & Senior Manager of Field Engineering for Australia & New Zealand at Pivotal. With over 24 years industry experience in everything from Mainframes to the latest Cloud architectures - Simon brings a refreshing and insightful view of the business value of IT. Passionate about technology, he is a pragmatist who looks for the best solution to the task at hand. He has held roles at EDS, PricewaterhouseCoopers, VERITAS Software, Hitachi Data Systems, Cisco Systems and Amazon Web Services.More Content by Simon Elisha