Your CI/CD Pipeline is a Production system with Stefan Prodan from ControlPlane
Cloud CommuteMay 31, 2024
1
x
14
00:28:5926.55 MB

Your CI/CD Pipeline is a Production system with Stefan Prodan from ControlPlane

Using CI/CD pipelines to build and deploy your applications is common sense. Many use combined tools though. Stefan Prodan, from ControlPlane, talks about the importance of recognizing that a deployment pipeline is basically a cluster admin and needs to be handled securely as a production system.

If you have questions to Stefan, you can reach her here:

If you want to try ControlPlane:

Additional show notes:

The Cloud Commute Podcast is presented by simplyblock (https://www.simplyblock.io)


01:00:00
When you get

01:00:00
started with

01:00:01
Kubernetes, it's very easy

01:00:04
and with the cloud-native

01:00:06
landscape. It's very, you know,

01:00:08
how do I solve

01:00:09
this? Oh, I add this

01:00:10
component, and I add this other

01:00:11
component, and I add this other

01:00:12
component, and

01:00:13
then you have, like,

01:00:15
10 key something controllers with

01:00:17
hundreds of configurations and so

01:00:19
on, right? So if you do

01:00:22
this in a, let's say, rush way, or

01:00:24
you do it as a proof of concept,

01:00:26
and that proof of concept ends

01:00:27
up being the thing that you are

01:00:29
running in production, you may

01:00:31
want to go over it and look,

01:00:33
how can I simplify this? Can I

01:00:35
take advantage of this component

01:00:37
and maybe eliminate other things?

01:00:39
Simplifying things usually means

01:00:41
you have a better understanding of

01:00:43
your system, and that makes the

01:00:45
system more secure.

01:00:51
You're listening to simplyblock's Cloud Commute Podcast,

01:00:54
your weekly 20 minute

01:00:55
podcast about cloud technologies,

01:00:56
Kubernetes, security,

01:00:58
sustainability, and more.

01:01:00
Hello, everyone. Welcome back to

01:01:01
the next episode of simpleblock's

01:01:03
Cloud Commute podcast.

01:01:05
Today with me I have Stefan.

01:01:08
Please pronounce the last name

01:01:10
yourself in a second.

01:01:13
I'm not going to try to do that

01:01:15
myself. But Stefan

01:01:18
joins us from ControlPlane.

01:01:21
Before that, I guess he's also

01:01:23
talking a little bit

01:01:24
about his own background.

01:01:26
So Stefan, welcome. And maybe say

01:01:29
a few words about yourself. Who

01:01:31
are you? Why are you here?

01:01:35
Thanks, Chris, for inviting me.

01:01:37
Yeah, I'm Stefan Prodan. I'm a

01:01:41
software engineer

01:01:42
for some time now.

01:01:43
And in the last seven years, I've

01:01:46
been focusing exclusively on open

01:01:50
source engineering.

01:01:51
I've been involved with the CNCF

01:01:55
FluxCD project for all this time.

01:01:59
And I've developed some of my

01:02:03
own sub-projects inside FluxCD,

01:02:05
like Flagger, for example, which

01:02:08
is continuous delivery

01:02:10
and progressive delivery side of

01:02:15
that. And yeah, I help architect

01:02:19
and shape the current version of

01:02:21
Flux, which is version two. And

01:02:23
yeah, my passion is around working

01:02:27
with the cloud native ecosystem

01:02:30
with Kubernetes and build

01:02:32
solution on top of that.

01:02:34
All right. Yeah, you said FluxCD,

01:02:39
and I think we're going to come

01:02:40
back to that in a second.

01:02:43
Right now, you're working with a

01:02:44
company called ControlPlane. And

01:02:46
from what I see on the website,

01:02:48
that is a security consultant,

01:02:51
cloud native security consultancy.

01:02:52
Let's put it that way.

01:02:54
So maybe say a few words

01:02:55
about the company itself.

01:02:57
Yeah, so the company is from

01:03:00
London, but we are distributed

01:03:04
around the globe. It's a security

01:03:08
company which focuses on thread

01:03:11
modeling, pen testing for

01:03:16
Kubernetes environments.

01:03:18
We do architectural designs for

01:03:21
your continuous integration and

01:03:23
delivery pipelines with focus on

01:03:25
security, of course, and

01:03:27
compliance. So yeah, our services

01:03:31
are more around helping

01:03:33
organizations evolve into their

01:03:37
cloud-native journey. And while

01:03:39
they are doing that, doing it

01:03:41
in a safe way, you know, you

01:03:43
should, if you are migrating to

01:03:45
cloud, you should, you know, gain

01:03:47
also a better security stance out

01:03:50
of it. And that's

01:03:51
one of our main focus.

01:03:55
Right, right. So that means from a

01:04:00
customer point of view, when I

01:04:02
joined as a customer,

01:04:03
what would a typical customer look

01:04:05
like? Is it like the big company

01:04:07
that, as you said,

01:04:09
is just moving into the cloud

01:04:11
game? And what are the challenges

01:04:14
they face and where you help them?

01:04:18
So there are a wide range of

01:04:20
customers. There aren't only banks

01:04:22
and financial institutions,

01:04:24
but those are usually the

01:04:27
companies that organizations that

01:04:29
are looking for,

01:04:31
you know, answering the questions,

01:04:33
are we really secure? Are we doing

01:04:35
the right thing here? And

01:04:39
I mean, it's not only about most

01:04:42
banks moved part of their

01:04:44
infrastructure a long time ago

01:04:44
on cloud, right? It's not about,

01:04:48
you know, getting them started

01:04:49
with, but it's more about,

01:04:52
you know, how the hybrid cloud

01:04:55
looks for you, which are the

01:04:57
challenges here. And when we go,

01:05:00
usually we do an architectural

01:05:02
review, we try to understand the

01:05:03
system there. And then, you know,

01:05:06
through pen testing, thread

01:05:07
modeling, and other practices like

01:05:11
that, trainings, we try to make

01:05:14
first the customer's employees

01:05:17
more security conscious of their

01:05:20
day-to-day operations,

01:05:25
and then come up with a

01:05:26
commendation for how they can

01:05:28
improve that. Also with pen

01:05:30
testing, we discover

01:05:32
all sorts of, you know, let's say,

01:05:34
misconfigurations, and we also

01:05:36
propose solutions

01:05:37
for that, but it's

01:05:38
up to the customer to actually,

01:05:40
you know, take that knowledge and

01:05:44
make their security

01:05:47
difference better. So it's a mix

01:05:49
around, you know, consultancy

01:05:50
going there to, you know,

01:05:53
red team type of analysis where

01:05:58
you poke around and see what you

01:06:01
find, but it's also about, you

01:06:03
know, looking at the architecture

01:06:06
of the whole thing and how that

01:06:08
can be improved. Usually,

01:06:10
improve one means also, especially

01:06:12
in the cloud-native world, means

01:06:14
simplification. Like, if you see

01:06:18
out there, like, I know me as a

01:06:21
Flux maker, I've talked to so many

01:06:24
users of Flux, which are,

01:06:26
I know, thousands, tens of

01:06:28
thousands, and when you get

01:06:31
started with

01:06:32
Kubernetes, it's very easy

01:06:34
and with the cloud-native

01:06:36
landscape. It's very, you know,

01:06:39
how do I solve

01:06:39
this? Oh, I add this

01:06:40
component, and I add this other

01:06:42
component, and I add this other

01:06:43
component, and

01:06:44
then you have, like,

01:06:45
10 key something controllers with

01:06:47
hundreds of configurations and so

01:06:50
on, right? So if you do

01:06:52
this in a, let's say, rush way, or

01:06:55
you do it as a proof of concept,

01:06:56
and that proof of concept ends

01:06:58
up being the thing that you are

01:06:59
running in production, you may

01:07:01
want to go over it and look,

01:07:04
how can I simplify this? Can I

01:07:06
take advantage of this component

01:07:07
and maybe eliminate other things?

01:07:10
Simplifying things usually means

01:07:12
you have a better understanding of

01:07:14
your system, and that makes the

01:07:15
system more secure. So, yeah, we

01:07:19
in the cloud-native world tend to

01:07:22
have, like, deal with massive

01:07:23
complexity, and yeah, that's one

01:07:27
of the things I'm seeing, like,

01:07:29
trying to reduce complexity and

01:07:31
reduce the noise. It's a good way forward.

01:07:35
Right. I think one of the

01:07:37
interesting things you mentioned

01:07:39
is pen testing, and pen testing is

01:07:41
always something that is dear to

01:07:44
my heart, because I did not do it

01:07:47
in a professional way in the past,

01:07:49
mostly for online games and stuff.

01:07:52
But I think it's a really

01:07:53
important process of actively

01:07:57
trying to break into systems or

01:08:01
break systems and to find those

01:08:04
issues before, well, hopefully,

01:08:06
the hostile actors find those. So,

01:08:09
I think this is really

01:08:11
interesting. That is something, I

01:08:13
don't know, maybe you have a

01:08:14
different feeling about that,

01:08:15
but I think it's still something

01:08:17
that is not really actively used

01:08:19
by a lot of companies, maybe

01:08:21
the big ones, but a lot of the

01:08:23
smaller companies still seem to

01:08:25
miss that, like, where they don't

01:08:27
really get the importance of pen

01:08:29
testing. What do you think about that?

01:08:34
Yeah, I mean, I first, I

01:08:36
came to Fosdem some years ago,

01:08:41
and Andy, which is the CEO of

01:08:45
ControlPlane, we worked on something

01:08:49
together, but I joined ControlPlane

01:08:52
this year, so I'm quite the

01:08:54
company. He had a talk on how to

01:08:56
hack Kubernetes and he was on

01:08:58
stage hacking Kubernetes from the

01:08:59
root container on the node. Okay,

01:09:02
now I'm on the node. How can I get

01:09:05
control of the whole control plane

01:09:09
of Kubernetes? And then,

01:09:11
yay, I'm cluster admin, and from

01:09:13
here, I can do whatever I want.

01:09:15
And yeah, I think we should

01:09:19
educate people more, Kubernetes

01:09:22
users through things like that,

01:09:24
you know, great talks.

01:09:27
We, at ControlPlane, also do

01:09:28
professional training around where

01:09:30
we actually teach people how to

01:09:33
hack their own Kubernetes. We have

01:09:35
a product called kubesim, which is

01:09:39
a Kubernetes simulator,

01:09:40
everybody gets a cluster, it has

01:09:42
all sorts of, you know, and all

01:09:45
sorts of, you know, you deploy in

01:09:47
our container, now shell-exacting

01:09:49
to it, and from there, you can go,

01:09:51
you know, sideways and

01:09:53
all sorts of things. And I think

01:09:56
that kind of mentality is

01:09:58
important to, you know, promote it

01:10:02
more. Like, yeah, every time there

01:10:06
is some way of getting around

01:10:09
security constraints, that should

01:10:11
things you have in place. So

01:10:13
poking around it, it can be fun,

01:10:16
and it also

01:10:17
teaches you a lot about

01:10:18
the system itself, you learn

01:10:20
better Kubernetes if you try to,

01:10:22
you know, exploit it from this perspective.

01:10:25
It's that's very true. It's kind

01:10:27
of the same thing. In the past, I

01:10:29
advocated a lot for how to build

01:10:33
resilient and full tolerant

01:10:34
systems. It's kind

01:10:36
of the same thing

01:10:37
from my perspective with security.

01:10:39
There is no way to build a 100%

01:10:41
secure system, except for you

01:10:42
don't build it at all. So embrace

01:10:46
the idea of there are security

01:10:48
issues, and in the worst case,

01:10:51
pay somebody to find them for you.

01:10:54
It's kind of the same thing with

01:10:55
resiliency, right? A resilient

01:10:57
system is nice, and you can

01:10:59
probably build like a 100%

01:11:00
resilient system,

01:11:01
but nobody will pay the

01:11:02
money for that. So it's a trade

01:11:05
off. Like, how much money do I

01:11:06
have in my bank, and how much is

01:11:08
this problem worth solving?

01:11:12
Yeah, vulnerabilities come at this

01:11:14
point, come to you

01:11:15
from all directions,

01:11:17
right? It's what we've seen in the

01:11:20
last years with, you know,

01:11:27
exploiting the

01:11:27
continuous integration

01:11:29
and continuous delivery pipeline.

01:11:31
And you don't even have to have

01:11:33
the production system. Maybe

01:11:34
that's bulletproof, but you can

01:11:36
get into some Jenkins server,

01:11:38
which is out there on the internet

01:11:39
with a hard coded admin password

01:11:42
that everyone can guess very

01:11:44
easily. And once

01:11:46
you are into the CI

01:11:48
system, and you can, you know,

01:11:53
poison those binaries or, you

01:11:54
know, deploy your own container

01:11:57
on the production cluster, even if

01:11:58
the production cluster is great,

01:12:02
you are there through the

01:12:04
pipeline, right? So right.

01:12:05
Or even worse, you're gaining the trust of

01:12:09
a maintainer over the years

01:12:11
of contribution just to sneak in

01:12:13
something into the CI CD pipeline,

01:12:16
which is the XZ thing was

01:12:19
like completely mind blowing to me

01:12:21
that somebody will invest so much

01:12:23
time up front just to

01:12:26
anyway. But you made a good bridge

01:12:32
to FluxCD, I

01:12:35
guess, right? You said one of the

01:12:37
important things right now is that

01:12:39
a lot of attack vectors are going

01:12:41
towards the deployment pipeline

01:12:44
or the CI CD pipeline, trying

01:12:48
to inject something at build time,

01:12:50
and getting it signed

01:12:52
or whatever you want to call it,

01:12:54
it looks like totally fine. And

01:12:57
it's still a perfect attack

01:12:58
vector. I think that is where

01:13:00
ControlPlane also plays into with

01:13:03
the enterprise and enterprise for

01:13:05
FluxCD. Is that it?

01:13:09
Yes. So yeah, FluxCD, being a

01:13:13
CNCF project, you

01:13:15
as a company, even if

01:13:17
you hire maintainers, you are not

01:13:19
allowed to say Enterprise FluxCD

01:13:21
because Flux is brand

01:13:24
of CNCF. So and we also, you know,

01:13:28
it's ControlPlane Enterprise for

01:13:30
FluxCD, some other company

01:13:31
tomorrow can offer the same thing

01:13:32
and there is their enterprise

01:13:34
opening for this

01:13:36
particular project.

01:13:37
So that's the meaning there. Yeah.

01:13:41
So with Flux, we basically what

01:13:44
Flux does, it's a way of

01:13:47
you to rip apart the CD things

01:13:51
from your CI CD. I truly think CI

01:13:56
CD shouldn't happen in one tool

01:13:59
or be a thing that's like this

01:14:02
huge monolith that builds all the

01:14:03
code, has access

01:14:05
to all the sources,

01:14:06
produces artifacts, then also

01:14:09
connects all your production

01:14:10
systems and deploys those.

01:14:13
Having this kind of monolith may

01:14:16
be sounds easier to get started.

01:14:21
But if you look from a

01:14:23
security perspective, and also

01:14:24
from a scaling perspective, it

01:14:27
becomes a single point of failure

01:14:29
and a major vulnerability

01:14:31
infrastructure that you have in

01:14:34
there. Also, there is this

01:14:36
mentality where,

01:14:37
you know, especially CI systems

01:14:39
are not people don't think of them

01:14:42
as part of your production

01:14:44
right. So, right, everybody has

01:14:49
access to the Jenkins cluster or

01:14:51
whatever. But production is

01:14:54
secure only as many people have

01:14:55
asked her well, if the CI system

01:14:59
has a kube config with cluster

01:15:01
admin, right, because it needs to

01:15:03
deploy all things on the cluster,

01:15:05
then you either think of

01:15:07
it as your production system, or

01:15:10
you adopt a pattern like GitOps,

01:15:14
for example, what what FluxCD

01:15:15
implements, where you move the

01:15:19
continuous delivery side inside

01:15:21
your production, where

01:15:24
thing that deploys on the cluster

01:15:26
is running in the cluster, and

01:15:28
it's subject to Kubernetes,

01:15:31
RBAC of Kubernetes, security

01:15:33
constraints, network policies, and

01:15:36
you apply the same, you know,

01:15:41
security mindset to your

01:15:42
continuous delivery tool as you

01:15:44
apply to the whole

01:15:45
production system

01:15:47
itself, right. So the the shift

01:15:49
with FluxCD and all the other

01:15:51
GitOps stores in the ecosystem is

01:15:53
the fact that it runs there in

01:15:56
production, and you don't connect

01:15:58
from outside from Jenkins or

01:16:00
whatever your GitHub actions, you

01:16:03
don't have to open your your

01:16:04
clusters on the internet,

01:16:06
you don't have to give some

01:16:07
external system your cluster

01:16:11
admin configuration and

01:16:13
authentication. But the cluster

01:16:16
itself goes somewhere and looks

01:16:19
there and says, Oh, this

01:16:21
is what I have to deploy, let me

01:16:23
deploy and that somewhere is the

01:16:26
Git repo that can be

01:16:29
different and should be different

01:16:30
in most ways than where you store

01:16:33
your source code. So you can

01:16:35
apply, you know, constraints on

01:16:41
who has access to the Git repository

01:16:43
where my production system is defined.

01:16:47
You can have a different type of, you

01:16:50
know, groups of people and how you

01:16:53
drive changes there, you can

01:16:54
enforce all sorts of good

01:16:56
practices that you

01:16:58
can enforce on any

01:17:00
Git repo, like main branches is

01:17:02
protected, and you have to every

01:17:05
time you modify something on a

01:17:06
cluster, you have to open up a

01:17:08
request, someone from the SRE team

01:17:09
has to approve it, oh yeah,

01:17:11
it's okay to change this network

01:17:12
policy, right, so you basically

01:17:16
apply all the good practices

01:17:18
that you have for your code to

01:17:20
your production systems, you can

01:17:23
keep these things in a separate

01:17:25
repository or repositories, and

01:17:28
then the production system comes

01:17:29
to the repository,

01:17:30
sees, oh, there is

01:17:31
a new version of this app, let me

01:17:35
now deploy it for you. So you

01:17:37
don't go to the system, the

01:17:39
production system comes to you and

01:17:41
decides how the new version should

01:17:45
be deployed. So it's

01:17:46
basically FluxCD if you think of it

01:17:49
as like a proxy between, you know,

01:17:53
the desired state which is a

01:17:54
Git repo and the production system

01:17:57
where it runs. So you no longer go

01:17:59
to the system and control it

01:18:01
yourself, you tell Flux, hey, I

01:18:03
would like for my cluster to look

01:18:05
like this, and Flux can tell you,

01:18:07
hey, this is not possible, I have

01:18:11
Kyverno or OPA in here and they are

01:18:14
blocking this change,

01:18:16
now go and figure out the fix for

01:18:18
it. So you can Flux

01:18:20
integrate with

01:18:22
admission controllers

01:18:24
which can enforce good practices,

01:18:29
better security constraints on top

01:18:31
of your continuous delivery

01:18:33
pipeline. So there is a continuous

01:18:35
delivery pipeline here in the

01:18:37
cluster and a CI thing

01:18:38
which is completely separated. So

01:18:40
just having this separation, you

01:18:43
know, improves your

01:18:45
security stance and you have a

01:18:49
more reliable way of

01:18:50
deploying it because

01:18:53
let's say like you start with one

01:18:56
production cluster, one region,

01:18:57
then your business grows,

01:19:00
right, maybe you move from US and

01:19:02
you open a shop in Europe as well,

01:19:04
you want the European

01:19:08
customers to not have huge

01:19:10
latency, right, not go to the

01:19:12
cluster in US, so

01:19:13
you'll probably create

01:19:14
a new cluster in European region

01:19:18
there. So the more your business

01:19:21
expands, the more

01:19:22
clusters you have

01:19:24
and what that means if you have

01:19:26
everything running from a single

01:19:28
CI CD tool, every

01:19:29
time you add a new

01:19:30
cluster you have to, you know,

01:19:32
onboard it into your CI system,

01:19:34
like setting up

01:19:36
certificates, how you

01:19:37
connect to it and all of that.

01:19:39
With something like Flux, when you

01:19:41
add a new cluster, you bootstrap

01:19:44
Flux which is the thing that after

01:19:46
the cluster gets created, the

01:19:48
first thing that gets deployed

01:19:49
there is Flux itself and then you

01:19:51
tell Flux, hey, configure this

01:19:54
whole cluster, this whole region

01:19:56
according to that repository where

01:19:58
you have defined your production

01:20:00
system, it automatically does it,

01:20:02
right, so it's easier to, you

01:20:05
know, expand your production

01:20:07
system over regions and so on

01:20:10
when you adopt something like like

01:20:13
GitOps in your pipeline.

01:20:16
That was amazing. I had so many

01:20:18
questions you had just answered

01:20:19
all of them. You literally just

01:20:22
went for answered all of them in

01:20:24
one go. That was absolutely

01:20:26
incredible. Just one quick

01:20:29
question because I

01:20:30
think a lot of the

01:20:32
audience may use something like

01:20:34
ArgoCD, in that sense it's kind

01:20:36
of similar, right? It's kind of a

01:20:38
similar idea that you separate out

01:20:40
like your build pipeline which

01:20:41
would be probably like Jenkins and

01:20:43
then you have Flux or ArgoCD or

01:20:46
something on the cluster side

01:20:47
installing or deploying all the artifacts.

01:20:51
Yeah, yeah.

01:20:54
So there are two main projects that

01:20:57
implement the GitOps pattern

01:20:59
instance here that Flux and ArgoCD.

01:21:03
There is also the continuous

01:21:06
delivery foundation and the Linux

01:21:07
foundation, CDF, where they host

01:21:11
the Jenkins X which is, it's a

01:21:16
rewrite of Jenkins that has

01:21:20
GitOps features. There is also

01:21:22
Tekton in CDF as a project which

01:21:26
does continuous, can do continuous

01:21:28
integration but can also configure

01:21:30
Tekton to do continuous delivery.

01:21:32
It also runs in your cluster

01:21:34
and there are other projects out

01:21:39
there which have or which have

01:21:42
begun implementing

01:21:43
GitOps features into it. So GitOps

01:21:47
is quite mature as a way of doing

01:21:50
continuous delivery right now.

01:21:52
It's far, far away from when I

01:21:56
started with it seven years ago

01:21:58
which felt like well what is this

01:22:01
GitOps thing? Right now people

01:22:04
like actually get it and GitOps

01:22:07
says the idea is not new,

01:22:10
is not something that we invented

01:22:12
in the cloud native space. It's an

01:22:17
idea, it's an old idea that

01:22:20
Puppet did the same exact thing way

01:22:23
before Kubernetes with the agents

01:22:27
and everything. So it's

01:22:29
the idea that you have some kind

01:22:31
of agent in your production system

01:22:34
that pulls the desired state

01:22:37
from outside and tries to change

01:22:39
the system and make it fit into

01:22:43
what you have described is

01:22:49
over 12 years old. Any practice.

01:22:53
Puppet did really good back then.

01:22:55
Yeah, I agree. The whole GitOps

01:22:58
thing, it's one of those things

01:23:00
which is around for a while

01:23:01
but never had a real name but

01:23:05
people have done it for quite a

01:23:06
while. So yeah, I agree.

01:23:09
In the sake of time because we're

01:23:11
already behind the 20 minutes but

01:23:14
I really want to ask you like

01:23:15
what is your personal view on the

01:23:18
future? What do you think is like

01:23:19
the next big thing? Is there

01:23:21
something you see coming as like

01:23:23
the next innovation of GitOps or

01:23:26
CD pipeline security,

01:23:29
whatever you think?

01:23:32
So for me,

01:23:34
what I am trying to

01:23:37
promote inside the FluxCD

01:23:40
organization and through the Flux

01:23:43
project and all the Flux

01:23:46
maintainers are

01:23:47
we try to drag Flux

01:23:49
in a direction where we offer a

01:23:55
different way of doing GitOps

01:23:57
without Git in production

01:23:59
but with Git still as the tool

01:24:02
that you use for

01:24:03
collaboration. So what we are

01:24:06
shifting into Flux and it's

01:24:08
already in there, we have

01:24:09
production users

01:24:10
using it, is where we use

01:24:13
the container registry as the

01:24:15
thing that holds your whole

01:24:17
desired state and we rely upon

01:24:23
the open container initiative

01:24:24
specification which I know since

01:24:29
two years ago, three years ago,

01:24:31
it has this concept of an OCI

01:24:33
artifact. So an OCI artifact is

01:24:36
what you are already using it.

01:24:41
If you use a container image,

01:24:43
that's an OCI artifact and it's a

01:24:48
tarball which has some

01:24:50
metadata and it's stored in the

01:24:52
container registry. Those are your

01:24:53
app images and with Flux,

01:24:56
what we've done is we are offering

01:24:59
tools also in the CLI and also the

01:25:02
controllers where you can say

01:25:04
I can do a Flux push which is the

01:25:07
same as a Docker push

01:25:09
but instead of pushing your

01:25:11
binaries with Flux push, you push

01:25:13
the configuration of your cluster

01:25:14
which can be all the Kubernetes,

01:25:18
YAMLs, custom resources, Helm

01:25:20
charts, all the definition of your

01:25:22
production cluster,

01:25:23
it's stored in the container

01:25:24
registry which by design is more

01:25:27
closer to the cluster. It's HA

01:25:31
and can leave inside your private

01:25:34
VPC next to the cluster where Git

01:25:36
did something that

01:25:38
it's usually outside of that trust

01:25:41
zone because developers have to

01:25:44
have access to it and so on.

01:25:45
So you will basically push the

01:25:47
configuration to your Git repo but

01:25:50
instead of Flux coming from

01:25:51
the cluster to Git and basically

01:25:54
getting over the security trust

01:25:58
zone in this area, you will push

01:25:59
the configuration along with your

01:26:03
when you do the Docker build and

01:26:04
Docker push right after that

01:26:06
will do a Flux push, the

01:26:07
configuration of that application

01:26:09
to the same container registry.

01:26:11
You sign it in the same way with

01:26:13
coastline or notation and when

01:26:16
Flux deploys the new version

01:26:18
of the app instead of going to Git

01:26:19
goes to the container registry,

01:26:21
pulls the definition there,

01:26:23
verifies that the definition is

01:26:24
correctly signed and only then it

01:26:27
deploys it. So it fits

01:26:29
in the security model and we are

01:26:33
also promoting this through our

01:26:35
ControlPlane offering for

01:26:38
for Flux the Enterprise Edition

01:26:39
where we want to ensure that

01:26:42
ControlPlane customers which are

01:26:45
relying on Flux, they can adopt a

01:26:48
more secure way and a better way

01:26:53
of doing continuous delivery not

01:26:54
only from only from a security

01:26:57
perspective but also from a

01:26:59
reliability perspective right because

01:27:02
you no longer have to get Git in

01:27:04
there in your production system

01:27:06
and you can rely on the container

01:27:09
registry which you should already

01:27:11
have it in there, you should have

01:27:13
figured out how to do a

01:27:14
change for it and if you are using

01:27:17
a cloud vendor you already have

01:27:19
all these things but no cloud

01:27:20
vendor out there will give you the

01:27:22
same SLAs and the same insurances

01:27:24
for a Git offering

01:27:27
in the way they do it for

01:27:29
container registry right so that's

01:27:31
that's where we

01:27:32
are moving with Flux.

01:27:33
That is a really interesting

01:27:36
approach and I never thought of it

01:27:38
like the container registry to me

01:27:40
always was like an image registry

01:27:43
basically that's an interesting

01:27:44
approach to just reuse the same

01:27:48
system and say okay now you

01:27:49
basically push your consider or

01:27:51
your suggested state and

01:27:55
on the other side you just pull it

01:27:57
and rebuild it. That's interesting.

01:28:00
Unfortunately we're out of time

01:28:02
I have a few more questions about

01:28:05
20 minutes are over so thank you

01:28:08
very much it was a pleasure I

01:28:10
hope people learned something.

01:28:11
I certainly learned something new I

01:28:13
only used ArgoCD in the past

01:28:15
so Flux is new to me and

01:28:19
thank you for being here.

01:28:21
Thank you Chris. Thank you for inviting

01:28:23
yeah and yeah please try Flux

01:28:25
you'll love it.

01:28:27
Yes please try

01:28:28
Flux and until next week next

01:28:32
week when you when you come back

01:28:33
and listen into the next episode

01:28:35
you have one week to try Flux now.

01:28:39
Thank you very much for being here

01:28:40
and hear you guys next week or you

01:28:43
hear me whatever.

01:28:44
See ya!

01:28:46
The cloud commute podcast is sponsored by

01:28:48
simplyblock your own elastic

01:28:50
block storage engine for the cloud.

01:28:52
Get higher IOPS and low predictable

01:28:53
latency while bringing down your

01:28:55
total cost of ownership.

01:28:56
www.simplyblock.io