Securing Hybrid Cloud: North‑South vs East‑West Traffic
Key Points
- The talk distinguishes **north‑south traffic** (user‑to‑data‑center/cloud) from **east‑west traffic** (service‑to‑service within a data center or cloud) as a foundation for hybrid‑cloud security.
- In traditional on‑prem monolithic apps, **perimeter security** (firewalls, badge access) and an **API gateway** protect exposed endpoints, placing most security responsibility on the application developer.
- Moving to a public or private cloud, the architecture shifts to **Kubernetes workers** where multiple micro‑services communicate internally (east‑west), requiring container‑level security and service‑mesh controls.
- At the cloud edge, providers add protections such as **DDoS mitigation and request authentication**, complementing the on‑prem perimeter and helping secure the north‑south traffic that enters the hybrid environment.
Full Transcript
# Securing Hybrid Cloud: North‑South vs East‑West Traffic **Source:** [https://www.youtube.com/watch?v=_bjDY9omL9I](https://www.youtube.com/watch?v=_bjDY9omL9I) **Duration:** 00:13:15 ## Summary - The talk distinguishes **north‑south traffic** (user‑to‑data‑center/cloud) from **east‑west traffic** (service‑to‑service within a data center or cloud) as a foundation for hybrid‑cloud security. - In traditional on‑prem monolithic apps, **perimeter security** (firewalls, badge access) and an **API gateway** protect exposed endpoints, placing most security responsibility on the application developer. - Moving to a public or private cloud, the architecture shifts to **Kubernetes workers** where multiple micro‑services communicate internally (east‑west), requiring container‑level security and service‑mesh controls. - At the cloud edge, providers add protections such as **DDoS mitigation and request authentication**, complementing the on‑prem perimeter and helping secure the north‑south traffic that enters the hybrid environment. ## Sections - [00:00:00](https://www.youtube.com/watch?v=_bjDY9omL9I&t=0s) **North‑South vs East‑West Security** - The speaker explains hybrid‑cloud security by contrasting perimeter (north‑south) traffic with internal (east‑west) traffic, using an on‑prem monolith example to illustrate firewall‑based protection and its impact on application developers. ## Full Transcript
hi everyone my name is psy venom and I'm
a developer advocate with IBM today I
want to talk about security with hybrid
cloud architectures this is going to be
part three of the hybrid cloud
architecture series security is a
nuanced topic but to kind of help me
explain I'm going to start with two
major concepts of north-south network
traffic versus east-west network traffic
when I walked into the office today I
had to pull out my badge and scan to get
into the building this is something
called perimeter security and it's a
core part of north-south network traffic
essentially what that refers to is any
traffic that's traveling from end-user
applications to your data centers or
public or private cloud environments
let's take a step back and kind of
explain these pieces here so we've
talked about this in the previous videos
but what we've got here is the stock
trader monolith which is gonna be on an
on-prem data center we've got a couple
of services here maybe something to help
us talk to the cloud and maybe a data
store as well so we mentioned perimeter
security and that's something you
honestly you take as a given with data
centers that you have that firewall
sitting in front of that data center
giving you a private network for your
actual data center and the applications
and workloads running within it this
made security a lot easier to tackle
when working with monolithic
applications but it did put the onus of
security on the application the
enterprise application developer the the
the main thing here to actually secure
these endpoints was to make sure that
all the capabilities that this monolith
exposes those API endpoints or secured
and to do that we could take advantage
of something like an api gateway so
traditionally what we would see is a
gateway that's set up in front of that
that on-prem application with key
capabilities exposed that may be
required by that front-end to render the
application and potentially the same for
a mobile app as well so that I think
helps tackle security with north-south
and network traffic on the on premise
side but let's shift gears here for a
second and talk about the public cloud
side or even potentially a private cloud
I'll talk about the different components
here later in the video but let's start
with this piece right here which is the
kubernetes worker within the kubernetes
worker we can assume that we have a
couple of services that we need to
actually render the stock trader
application whether it's mobile or in a
web app so I have a couple services you
can assume they talk to one another so
what happens when an end-user actually
accesses that application well one
they'll actually have to hit that
endpoint that becomes available at which
point they will enter the public cloud
and at that layer we get things like
denial of service protection and other
kind of things that the cloud provider
offers you to make sure that those
requests or maybe authenticated or you
know they're they're coming in in a safe
manner
the next thing that happens that
requests will get forwarded to your
actual kubernetes worker node with the
capabilities that it exposes so at that
level we have a couple of options for
securing those endpoints so let's say
you know we want to hit this first micro
service running in a kubernetes worker
there's two ways that we can kind of
configure security policies the first is
gonna be at layer 3 which is if you're
familiar it's it's things like IPS and
ports basically allows you to configure
policies for any network interface
that's gonna be done with things like
calico or the native kubernetes api
policies so that handles the the layer 3
security level the other option we have
here is to use something like Sto for
layer 7 network policies and and routing
for security together with those two
capabilities we can cover everywhere
from layer 3 to layer 7 network security
policies so the request comes in and you
know granted that it passes those
policies gets forwarded to your worker
and whatever services it might hit so
this is the ingress application flow and
then for external requests that a
service might make for egress calls you
know the same can be configured in sto
or calico going everywhere from layer
three to layer seven so that kind of
talks about north-south traffic ingress
and egress so communication with the
clients as well as the data center or
public private cloud environments so
that tackles north-south network flows
next let's talk about east-west so these
are going to be essentially
communication happening between services
running on Prem or in your public
private data cloud environments so for
east-west going back to my analogy so I
badge tin to my building they let me
into the perimeter but to actually get
to my floor where I where I work every
day I have to badge again and that's
going to be on it's actually the third
floor of the building right so I go up
to the third floor and I'm forced to
actually scan my badge again if I tried
to enter the fourth floor I actually
wouldn't be allowed to enter as I'm not
on the design team so essentially what
that refers to is a concept called
segmentation so within the actual
building or an application
infrastructure maybe a public cloud
environment we want to create segments
of what users are allowed to access what
admins are allowed to access what
processes are allowed to access when
when talking to one another so at that
level we actually call this an customer
or in kubernetes environments we call
that micro segmentation so in the
customer managed environment what that
would look like is essentially setting
up using something like sto TLS between
all requests going between micro
services the thing about encryption it's
one of those things that you want to
encrypt any requests as early as
possible and decrypt as late as possible
so with traditional kind of kubernetes
micro services architectures you want to
make sure that all of those requests are
being encrypted at the earliest level
possible
so that's kind of handles micro service
- micro service architecture but we
didn't really need to consider that with
the monolith because again as we
mentioned monoliths would be using RPC
or remote procedure calls software based
calls which remove the requirement of of
you know talking over a network so we
wouldn't actually have to take advantage
of TLS but you can imagine that you do
want to make sure that the the network
calls may be made to the database would
be secured
TLS the next concept I want to introduce
is what we've have sketched out here on
the cloud manage side of our cloud so
what we've got here is the kubernetes
master node and one thing to kind of
remember here is that when you're
working with a managed kubernetes
service the the master node is actually
going to be managed by the cloud
provider so whereas you control the
worker nodes the master is completely
managed and houses a very important
piece of the architecture the @cd data
store so in the kubernetes world that CD
datastore is something that you want to
be really careful about protecting
because that has all the information
about your services your deployments and
all of the kubernetes api resources so
secure in that CD is going to be very
important it's paramount to your
security architecture and to secure that
a cloud provider traditionally will have
a kind of a three phase process so what
we'll have is everything from we'll
start with step 1 which is
authentication so TLS next we've got our
back which is kubernetes role based
access control for authorization and
then finally over here the last piece of
that puzzle is going to be the admission
controller which is a kubernetes concept
that you know once you've made it
through the authentication and
authorization there's another level of
security to make sure that those API
requests are our Mutai
or you know massaged and made sure that
they're in the right format to access
that data so they'll access that EDD
data and to send that back to your work
or note where your application pods need
to request that information or or you
know pass information to it there's a
Open VPN server and there's also going
to be a client as well but that's going
to enable you to basically access that
EDD data store and return data back into
the kubernetes worker so that kind of
covers the the pattern of how kubernetes
is set up in a cloud provider service
with master node being managed and the
worker node being able to kind of work
with that master node in a secure
fashion to make sure your assets are
protected at all times the other thing I
want to mention here that EDD city data
store is gonna be backed up is about
this arrow here that EDD CD data store
is going to be backed up in a cloud
object storage capability to make sure
that you know worst case scenario you do
have those those assets in a secure
place so I think that covers you know
north-south network traffic as well as
east-west where we talked about network
traffic coming in from clients or at
least network traffic going between
services from your data center and your
private environments private or public
cloud environments the last thing I want
to talk about is a concept called dev
sec ops notice here that you know it's
essentially dev ops with the word
security right in the middle and
essentially it's a way to ensure that
security is something that you think
about from the ground up when you start
architecting the application all the way
until you move into production and
that's something you want to take
advantage of to make sure that you know
you don't have any any issues when we're
moving to production you don't want to
architect an application the incorrect
way and then realize you have to go back
and rework all of that so thinking about
security from the beginning is going to
be
an important thing when working with a
cloud provided kubernetes service
there's something that makes it a little
bit easier to to make sure your flows
are secure and one one consideration you
want to have here is to make sure that
your CI workflow that DevOps flow has
security embedded within it and is
automated so you can imagine maybe you
have your favorite kind of code
repository holding your application code
your your docker files whatever they
might be I'm going to automate that
process and make sure that you know
maybe only the developers who are
building that code have access to that
git repo next you want to make sure you
have a trusted signer to make sure that
that code when it gets pushed into a
registry well will go ahead and sign it
as a trusted image which is something
that's available with the cloud manage
registry so we'll push that image into
that registry once there there's the
capability called vulnerability advisor
that's going to scan that image and make
sure that there's any issues or any
vulnerabilities that are detected
everywhere from the base operating
system to may be the runtime that you're
using that if a vulnerability is
detected you'll be made aware of it once
it passes that vulnerability assessment
you can tie that in to build that image
and push it directly into kubernetes at
that stage you can use something like an
admission controller which we talked
about in the kubernetes master an
admission controller to make sure that
that image is again secure and without
vulnerabilities and finally there's an
live scanning capability to allow you to
scan your images running in production
to make sure that there's no
vulnerabilities in there so dev sack ops
an important a very important concept
that ensures that from the ground up
you're managing security when doing
DevOps thanks for tuning in to part
three of the hybrid cloud architecture
series on security if you haven't
already be sure to check out the
introduction part 1 and part 2 the links
will be below as always feel free to
subscribe if you want to see more of
these videos in the future thank you