All Posts in “Cloud Architecture”

Bowling Alleys Don’t Make Good Clouds

/ / Cloud Architecture, Enterprise Design Considerations, vDM30in30 / Leave a Reply

It’s not always either or, to often we present IT choices as though they were strictly black and white. Here’s why I think that is, because there are those in the industry that have only worked on the vendor side. This presents such a slanted view of the world. The one thing I have learned from the vendor side is vendors listen to industry analysts to figure out where disruption will come from and they try to skate to the puck. As I have said many times this doesn’t always match up with the maturity of their customer bases. The thing is we are trying to position cloud native apps as bowling alleys and not as buffets. At a bowling alley you are assigned a lane, given specific shoes, and told to pick from one of the various heavy balls. That’s pretty restrictive, when in reality cloud native apps are much more like walking down a Vegas buffet line. You can find just about everything on that table, none of it may be as good as you could get in each cuisines niche restaurant but it’s all serviceable. Cloud native apps are about mixing capabilities and leveraging existing external services to accomplish complex tasks.

This means that some of your services may be sitting in different clouds than your application code. If you are architecting right it’s about multiple clouds coming together from a cost competitive scenario as well as a vendor lock-in avoidance perspective. But it can also mean that hybridity of service applications could be necessary which may even include on-prem.

I was talking to Tyler Britten about this whole P2\P3 delineations and he pointed out that I may have been looking at it wrong. I had drank the kool-aid and wasn’t seeing the grey area.

The reality is the inter-dependencies of an application have to be managed when the application is grown at scale. For most traditional infrastructures this meant scaling each dependency as necessary like a multi-tiered architecture what we have called Platform 2. As we look past those traditional applications and onto the Cloud Native Apps with their micro-service builds we realize that the services come as containers themselves. I know I was disappointed too. It’s that the segmentation of monolith applications are just broken out to be 12 Factor consumable. This stinks but like a child finding out about mythological beings not being real I had to press on. So if I am just looking at containers am I understanding that they are isolated delivery modules better suited for mass distribution of an application. Maybe I was wrong about everything. As Tyler explained if we look at containers the distributed application dependencies aren’t always in other containers nor are they built as part of the container itself. Apparently containers can also be a hybrid app isolation, where large scale Oracle RAC could be the DB backend for a handful of containers deployed and managed via Chef, Puppet, Salt or Ansible.

It was like that weird commercial on TV where the people have their mine blown and purple smoke pours out. Because doesn’t the mixing of monolith and micro make strange bed-fellows or at the very least circus side show freaks. No it turns out that it actually makes a lot of sense. Next time I go to the bowling alley I am going to ask for bowling flip-flops and use a duck-pin puck instead of a ball. You can’t tell me how to do this Mr. Bowling Alley Operator, after all what are you going to do spray me with the shoe disinfectant?

NSX and Securing Multi-tenancy Policy

/ / Cloud Architecture, Security, vDM30in30, VMware / Leave a Reply

Discussing security and multi-tenant cloud environments both public and private consumes so much of my time. This time though let’s get into how micro-segmentation and the coolness that is VMware’s NSX. At least it’s a different angle so I don’t get bored writing about it J.

From an Operations perspective I want my environment to be as simple as possible, and consistently deployed. As I add tenants to my infrastructure this becomes even more imperative, right? Think about it this way if you are a car mechanic you can be a mechanic at a dealership and see similar vehicles all day let’s say Audi for example. Or you can work at a boutique shop and see every kind of vehicle. The benefit of the dealership is they can roll through more cars per day on average than a boutique shop because all of the cars are roughly the same lay out and use the same size nuts and bolts etc. Essentially the mechanic has the blueprints for the cars they are servicing.

In Operations if we have the same management stack across everything we have the blueprint and it’s simple. Enter the security team …

In security simple is also important, BUT, we also need to have gates and gate keepers. In a multi-tenant environment regardless of the M&O be it vRA or XStream we need to ensure that one tenant’s data can not corrupt another’s. Equally important we have to make sure that if\when a tenant is compromised (get your head out of the gutter) that compromise doesn’t trickle to my core infrastructure or to other tenants.

“Obvi Mike!”

Yeah I get it but that’s not as obvious to everyone, because think about what this means. First it means you need separate attack surfaces. In VMware terms this means two vCenters, one to manage the core infrastructure and another to manage the tenant infrastructure. This ensures that in the event that you get attacked and your tenants get PWND you still have a layer between the tenants and the core infrastructure that manages it all. It also means you have a stretched network for management. This creates a vulnerability in and of itself because it stretches across the core infrastructure and tenant architectures. However, we do not provide access to this management network from tenants directly rather we create jump servers or dual homed transitional boxes.

In NSX terms: We have controllers spanned across the environment, each tenant has it’s own NSX Edge and it’s own set of VXLANs. The Management network is linked off of whatever the M&O service is and provides visibility into the tenant for management but does not allow tenant traffic to jump across to other tenants. This is done by creating a distributed Firewall with ACLs for specific traffic on one of the M&O VM’s vNICs. It would be possible to also NAT this traffic across the Edge Gateway from tenant to management for the necessary monitoring and orchestration traffic.

If that all sounds good, then your next question is how does this work? Rather than reinventing the wheel I would recommend you read Matt Berry & Anthony Burke’s post on zero trust solution architecture with NSX. I think it best captures the right way to segment environments for security.

What do you think? Is this a little to security crazy or is this the way you would architect your multi-tenant environments?

Multi-tenancy means what exactly?

/ / Cloud Architecture, Enterprise Design Considerations, Enterprise Solutions, vSpecialist, What is Cloud? / Leave a Reply

This blog may just turn into a vocabulary lesson for IT people. Today’s word is multi-tenancy.

courtesy of Rob Nolen

Multi-tenancy is part of cloud design that enables shared resources and infrastructure. Those of you, who know me, know that I work for EMC covering the U.S. Federal Gov as a vSpecialist. So I will default to the NIST standard first the term Resource Pooling is used in the NIST Cloud Definition Guidance:

Resource pooling – The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth

Then in the Guidance for Security and Privacy in Public Cloud computing we find this:

Shared Multi-tenant Environment. Public cloud services offered by providers have a serious underlying complication—client organizations typically share components and resources with other consumers that are unknown to them. Rather than using physical separation of resources as a control, cloud computing places greater dependence on logical separation at multiple layers of the application stack [Owa10]. While not unique to cloud computing, logical separation is a non-trivial problem that is exacerbated by the scale of cloud computing (e.g., [Bos11]). An attacker could pose as a consumer to exploit vulnerabilities from within the cloud environment, overcome the separation mechanisms, and gain unauthorized access. Access to organizational data and resources could also inadvertently be exposed to other consumers or be blocked from legitimate consumers through a configuration or software error [Opp03]. Threats to network and computing infrastructures continue to increase each year and become more sophisticated. Having to share an infrastructure with unknown outside parties can be a major drawback for some applications and require a high level of assurance pertaining to the strength of the security mechanisms used for logical separation.

NIST doesn’t completely define multi-tenant models, does it? Nope part of that is due to the fact that the standard is watered down by the industry to ensure they can continue to support customers. No knock on NIST here because it has to be a tough job to create a standard for an entire industry. The way NIST builds the standard is partially through industry input; they look at what is available, what is coming and set definitions and guidelines based off of their insights. Sometimes this leads to solid guidance and clear direction, other times it leads to a loosely coupled series of semi-defined concepts. This is certainly one of those times.

So where do we then turn for guidance? How about the NSA? The NSA defines multi-tenancy thusly:

Multi-Tenancy – Multi-tenancy is the sharing of a common cloud resource that allows the cloud provider to efficiently utilize resources for multiple tenants and can be applied to all three cloud services (IaaS, PaaS, SaaS). Sharing resources, however, could result in residual data or operations being visible or discoverable by another user due to vulnerabilities or insecure configurations. There are varying degrees and definitions of Multi-tenancy among cloud providers and many providers have the option of not sharing resources at an additional cost.

Hahaha ok sorry clearly we need to go outside of the government if we want clear and concise on this topic, terms that the government is not known for. Since I have been beating on Gartner lately let’s see what Forrester has to say about this.

Our definition: Multitenancy defines IT architectures that let multiple customers (tenants) share the same applications and/or compute resources with security, reliability, and consistent performance.

Our research yielded three major findings about multitenant architectures. These are:

  1. Multitenant architectures must strike a balance between sharing and security. To deliver cost savings and scalability, a multitenant architecture must be able to manage dynamic resource consumption by its tenants without violating their security. These two goals ultimately conflict with one another, since shared resources and individual security rarely go hand in hand.

  2. Two common multitenant architecture models have arisen. Dedicated resource models stake boundaries within shared infrastructure, defining the resources a tenant can access, allowing for tangible and secure walls but lower flexibility. Metadata map models chart protected pathways to shared resources, allowing for increased flexibility, but they ultimately may feel less secure.

  3. Despite resource sharing, multitenancy will often improve security. Most current enterprise security models are perimeter-based, making you vulnerable to inside attacks. Multitenant services secure all assets at all times, since those within the main perimeter are all different clients. Leveraging a mix of dedicated resources and metadata map architectures, these services can deliver stronger security.

You know what I can live with this, because at the end of the day it does actually depend.

We will never get everyone to agree to the definition of something life multi-tenant until we reach the utilization stage of solution maturity. Cloud is maturing but it’s not there yet. In the mean time we just need to know that everyone is trying to position their solutions as multi-tenant. If you are reading this odds are you are in a position to advise or make IT decisions so you need to know that words and language have power (I know I have said it before). Understanding that things some products are built for hybrid cloud management like vRealize Automation are only meant for multi-tenant for a single organization (as of today). That public cloud management solutions that logically separate shared resource multi-tenant solutions not without risk. Multi-tenant dedicated resource backends are expensive but they lack the issues found in logical separation from hardware and networking but tend to find front-end issues with portals or the ever present user created security gap.

Education and understanding help to lead you to intelligent and open-eyed decisions, which means you can mitigate, accept, or minimize the risks you take. Multi-tenancy will be defined by the customer so let’s make sure we all define their understanding of the word clearly to assist them in making the best choice possible.