►
From YouTube: Using Argo Project to Help Elastic infoSec Team in Securing Elastic Christopher Cutajar & Angel Rios
Description
Using Argo Project to Help Elastic infoSec Team in Securing Elastic - Christopher Cutajar & Angel Rios, Elastic
InfoSec’s Security Engineering (SecEng) team at Elastic builds and maintains a collection of K8s clusters using Elastic Cloud on Kubernetes and Helm. Such clusters are used by the InfoSec team for various security use-cases such as vulnerability management, security assurance, threat intelligence, security detection and incident response amongst others. To be able to provide a reliable service and keep up-to-date, the SecEng team leverages various tool sets within the Argo Project that makes it easy and efficient for the team to manage. ArgoCD is used to deploy various ElasticSearch clusters that ingest logs from various different sources such as Qualys, Endpoints, Okta, AWS, GCP, Azure, GitHub and others. Clusters need continuous attention, Argo Notifications was configured together with ArgoCD to be able to keep abreast of the environments. Being a GitOps driven team, Argo Workflows and Argo Events are being leveraged to manage a number of microservices. In this session we’re planning to showcase how easy it is for a team to go from a small proof-of-concept to production in a very short period of time! Not only that, showing how to start evangelizing Argo within the organization.
A
Argo
is
enabling
us
to
secure
Alaska,
so
I
am
Angel
reels
I'm.
The
team
lead
for
the
security
engineering
team
at
elastic
I'm
based
in
Massachusetts
I've,
been
at
elastic
for
three
and
a
half
years
and
prior
to
elastic.
I
worked
in
the
financial
services
area
and
I
was
still
responsible
for
security
operations,
threat,
intelligence
and
identity.
Access
management
and
I
have
a
bachelor's
information
technology.
A
Here,
the
security
engineering
team,
we're
responsible
for
infosex
infrastructure
Services,
we
host
everything
in
kubernetes
and
our
main
job
is
to
keep
up
the
services,
build
infrastructure,
but
give
the
detection
team
visibility
into
what
is
happening
in
our
environment.
And
we
do
this
by
using
our
file
being
out
of
B
in
our
connectors
to
feed
data
into
the
stack.
So
our
detection
team
can
build
those
detections
but,
most
importantly,
we
also
are
kind
of
the
main
feedback
loop
to
the
product
team.
A
We
test
Bill
candidates
before
they're
released,
so
we
can
use
those
features
in
a
real
life
setting.
So
we
use
all
the
production
data
we
make
sure
that
the
product
could
scale
and
the
features
do
what
they're
supposed
to
do.
So,
hopefully,
we
find
the
issues
before
our
customers
do,
and
we
also
provide
feedback
to
how
we
can
make
the
product
better
and
try
to
add
new
features
into
the
roadmap
that
customers
can
eventually
use.
A
A
We
don't
want
to
operate
in
a
vacuum,
we're
trying
to
decentralize
security
because
everyone's
responsibility
to
protect
an
organization,
so
we
take
all
of
the
kind
of
the
high
level
road
maps
and
plans
of
each
of
the
teams,
and
it's
all
built
into
the
stack.
The
stack
is
at
the
heart
of
everything
that
we
do
and
we're
going
to
give
you
a
quick
example
of
how
we
do
that
for
folks
who
are
not
familiar
with
the
elastic
stack
at
the
core
of
everything
we
do.
A
We
have
elasticsearch
and
that's
what
stores
and
allows
you
to
search
your
data
below
that
as
I
mentioned
earlier,
we
have
many
connectors
and
Integrations
to
get
your
data
into
elasticsearch,
so
yeah
follow,
beat
Metro,
beat
rdb
Etc,
there's
several
of
them.
Go
to
our
page.
You'll,
see
all
the
various
ways
to
get
the
data
in
and
on
top
of
elasticsearch
you
have
Cabana
Cabana
allows
you
to
explore
visualize
your
data
and
take
action
on
it.
A
The
beauty
of
the
the
stack
is
you
have
a
central
platform
that
you
have,
that
has
multiple
Solutions,
so
you
have
security,
observability,
Enterprise
search
that
allows
you
to
slice
and
dice
your
data
as
you
as
you
need,
and
it's
already
in
an
elasticsearch.
So
it's
it's
really
powerful
to
just
leverage
the
stack
natively
to
dice
your
data,
so
you
wouldn't
have
an
infosec
team.
You
didn't
have
challenges
I!
A
So
one
of
the
challenges
we
have,
we
don't
have
a
kind
of
a
central
Network
where
everyone
connected
to.
So
we
need
to
get
all
the
different
data
sources,
so
we
can
make
sure
that
the
folks
connecting
in
are
the
appropriate
elasticians
and
we
have
to
collect
all
the
various
data
sources
from
the
different
Cloud
providers,
feed
them
to
the
stack.
So
we
have
quite
a
bit
of
data
fitting
into
our
stack
and
and
our
detection
team
ensures
that
they're
taking
action
on
anything
that
might
be
malicious.
A
As
you
can
see
here,
we
have
our
our
kind
of
operating
procedure.
Is
we
we
have
dedicated
elasticsearch
clusters
for
different
workloads
and
we
try
to
to
keep
it
this
way
to
make
it
a
little
easier
for
us
to
scale
and
keep
track
of
what
clusters?
What
but
the
beauty
of
elasticsearch
is.
We
have
a
a
feature
called
across
cluster
search
which
allows
us
to
have
one
elasticsearch
cluster
act
as
the
main
search
head.
A
This
has
the
ability
to
connect
into
all
the
various
elasticsearch
clusters
that
you
may
have
and
return
the
data.
So
our
detection
team
uses
this
to
build
all
the
detections.
We
also
use
it
to
to
help
us
with
all
of
our
metrics
because
it
has
ability
to
go
to
all
the
individual
clusters.
You
no
longer
have
to
go
into
the
individual
clusters
to
search
you
know
heartbeat
heartbeat
per
se.
You
could
just
go
to
one
stop
one
place
and
search
it.
A
So
here's
exactly
how
we
used
to
maintain
the
environment.
So,
behind
the
scenes
you
have
everything
as
I
mentioned,
is
in
kubernetes.
You
know
we
have
eight
different
clusters
in
the
past.
We
would
go
into
each
of
the
Clusters,
deploy
the
the
the
values
file
using
Helm
and
then
kick
it
off,
and
we
would
do
this
eight
eight
times
so
rinse
and
repeat
the
the
issue
with
that.
Was
issues
came
up
it.
We
would
have
to
then
go
back
to
that
cluster.
A
I've.
Never
done
this,
but
I
think
there's
I've
heard
someone
do
it.
They
actually
deployed
the
wrong
configurations
to
the
the
wrong
the
the
wrong
cluster.
So
we
built
guard
rails
to
protect
against
that,
but
what
the
beauty
of
Argo
does
is,
instead
of
us
having
to
go
into
individual
clusters
and
deploy,
we
develop
a
kind
of
a
workflow
to
deploy
to
changes
using
GitHub.
We
have
someone
from
security
operations,
I'm.
A
So
we
have
Argo
alerts
in
that
back
corner
over
there
telling
us
what
action
is
taken,
whether
or
not
the
deployment
is
synced
correctly
or
there's
failures.
That
goes
into
our
slack
Channel,
where
we
monitor
our
alerts
from
argocd
also
alerts
from
Cabana,
because
we
still
use
the
stack
as
an
observability
tool
and
all
that
goes
into
our
slack
channel
for
us
to
take
action
on.
So
this
is
our
Argo
Journey.
A
We
started
off
with
an
initiative
called
self-healing
infrastructure,
our
main
goal
there
was
to
take
alerts
that
are
generated,
Ali
Cabana,
that
we
were
High,
Fidelity
alerts
that
something
was
wrong
and
have
a
machine
or
a
mechanism
automatically
take
action.
A
good
example
of
this
was
we
had
a
Shard
that
that
was
kind
of
that
went
from
green
to
Yellow
and
if
we
could
automatically
go
in
and
have
a
mechanism
do
a
sink
or
try
to
adjust
it
and
fix
that
Shard.
A
Why
not
do
it
instead
of
us
manually
having
to
run
it
any
API
script?
So
we
started
going
down
that
path.
We
realized
that
Argo
had
the
ability
to
manage
kubernetes
resources
and
also
had
the
ability
to
take
a
commands
from
a
web
hook
and
take
action
on
it.
So
we
started
experiment
through
Argo
events.
A
A
And
next
thing
you
know
we
started
to
see
if
Argo
can
help
us
with
our
certificate
management,
where
we
had
expired
certificates
and
since
we're
running
elastic
cloud
and
kubernetes
that
automatically
handles
our
certificates.
But
if
something
is
about
to
expire,
it
used
to
be
a
manual
effort
for
us
to
kick
it
off
and
we
decided
to
to
use
Argo.
A
So
we
moved
into
production
and
it
started
handling
some
of
our
production
workloads
and
fixing
it
fixing
our
workloads
and
then
we
were
like,
since
it
could
take
action
on
the
resources.
Why
not
allow
our
go
to
automatically
help
us
with
all
of
our
upgrades
and
configurations?
So
we
then
made
a
change
to
automatically
have
our
Argo
kickoff
upgrades
as
we
merge
code
I,
say:
I'll.
Take
that
back.
It's
not
necessarily
automatically,
there's
still
a
sync
process
which
we
haven't
got.
A
We
haven't
had
the
faith
yet
to
have
Argo
kick
it
off
yet,
but
that
is
on
our
project
roadmap
as
we'll
discuss
a
little
later,
but
it
is
managing
all
of
our
clusters
and
it
tells
us
whether
it's
in
sync
out
of
sync
and
we're
getting
a
lot
of
article
notifications
in
regards
to
what
access
it's
taken
and
as
I
just
mentioned
there.
I
just
reveal
that
we're
using
our
goal
of
publication.
A
B
B
Certificates,
so
our
close
cluster
research
configuration
is
very
important
to
us,
especially
for
the
incidence
analysts
that
have
a
one
single
place
to
go
into
and
search
across
clusters.
So
they
don't
have
to
go
into
different
clusters.
So
it
is
important
for
us
to
keep
it
at
least
24
7
365
a
days
available
for
the
users,
and
one
thing
is
that
on
a
daily
basis,
there's
or
more
frequent
basis,
there
is
a
certificate
that
needs
to
be
refreshed
to
be
able
to
have
their
head
cluster
connected
to
the
remote
cluster.
B
So
all
our
endpoints
are
monitored
using
heartbeat
and
cable
and
uptime,
and
we
have
an
alert
where,
prior
to
our
goal,
pattern
out,
whereby
once
a
certificate
is
going
to
expire
within
15
days,
we
get
a
select
notifications,
say:
hey
folks.
Your
certificate
is
going
to
export
in
15
days.
Please
update
and
also
create
a
GitHub
alert
for
us
to
be
able
to
take
that
action
and
into
our
Sprint.
B
So
what
we've
done
and
what
are
Google
faster
flexibility
to
do
is
to
automate
the
whole
creation
and
upgrading
of
this
certificate
so
using
and
I'll
go
workflow
and
event.
Once
the
certificate
is
going
to
explain,
kibala
triggers
this
like
alert,
but
also
trigger
Argo,
to
be
able
to
imply
created
others
and
upgrade
all
clusters
within
your
certificate.
B
Basically,
it's
a
questionnaire
that
a
prospective
client
sends
to
an
organization
for
security
reasons
with
different
security
questions,
and
what
we've
started
to
do
sorry
is
to
make
all
our
information
and
all
our
questions
as
public
as
possible
across
elastic.
So
we
have
this
cat
service
customer
search
that
have
this
data
available
to
all,
to
all
elastic
faults
and
at
the
behind
the
scenes.
This
is
all
managed,
you're
using
Argo
to
make
to
keep
it
up
to
date,
and
the
next
slide
will
show
how
how
it
works.
B
So,
basically,
everything
is
in
GitHub,
once
an
infosette
creates
a
PR,
and
this
merge
GitHub
via
gets
hop
web
hook.
Argos
triggers
and
Ergo
then
download
the
latest
version
of
GitHub
via
a
ruby
script
that
we're
using
by
the
CSA
the
cloud
security
Alliance
repository,
published
and
automatically.
We
push
the
new
content
or
the
the
latest
version
to
elasticsearch
and
also
to
app
search
which
which
leverage
the
service
would
previously
Illustrated
in
the
previous
slide.
B
On
top
of
that,
we're
using
the
caiq
Excel
sheet
also
published
by
the
CSA
and
which
basically
try
to
be
a
little
bit
more
proactive.
So,
basically,
once
this
data
is
updated,
Argo
creates
the
Excel
sheet
and
Via
will
be
the
success
it
is
created
and
updated.
Then
we
push
it
to
a
cloud
storage
bucket
and
then
I'll
go
refreshes.
The
self-service
compliance
Port
that
we
make
this
Excel
sheet,
publish
to
all
elastic
and
elastic,
says
folks
to
be
able
to
share
it
with
with
a
prospective
client.
B
The
next
and
I
think
the
most
important
use
case
for
us
is
the
argosity
LS6
search
deployment
and
configuration
upgrades
again,
as
an
angel
mentioned,
the
sort
of
we're
not
going
to
into
the
detail
of
how
Argosy
directs,
because
everything
is
public.
Documentation
is
Territorial
and
it's
very
useful
and
it's
would
be
used
as
for
us
to
go
into
deep
life
here.
So
basically,
the
process
would
be
once
a
security
engineer
raises
a
PR
which
would
include
either
an
upgrade
or
a
conflict
change
for
the
cluster.
B
That
PR
is
reviewed
by
a
second
engineer
and
then
once
merged
Argo
will
notice
that
it's
there's
a
new
version
of
of
the
configuration
and
at
this
point
any
conflict
changes
or
any
upgrades
within
the
Clusters.
We
still
push
the
sync
button.
We
have
a
side
process,
that's
through
using
the
automatic,
the
automation
sync
which
works
impressively,
but
for
now
for
the
critical
infrastructure.
B
For
us,
we're
still
using
the
sync
at
that
point
once
with
regard
to
zinc,
was
to
get
an
Argo
notification
to
our
slack
and
all
of
this
we're
using
an
application
set.
So
basically,
all
our
configuration
again
is
in
GitHub
both
from
the
gets
cluster
IPS
names.
I
just
have
charts
Etc
within
this
application,
set
we're
also
highlighting
what
particle
notifications
we
want
to
send
to
our
select
message:
we're
not
using
the
full-fledged
alerts,
because
keyboard
already
provides
white
and
monitoring
data
for
us,
but
we
want.
We
want
it.
B
A
little
bit
more
and
I'll
go
CD
is
giving
us
the
supporting
to
make
a
whole
visibility
of
the
infrastructure
and
then
the
final
Hampshire
deployment.
Again,
everything
is
within
GitHub
and
the
addition
of
that
is
apart
from
before
we
went
to
also
go
into
each
cluster
to
check
the
logs.
We
check
everything
we
can
within
Argo
City
UI
for
all
clusters.
We
check
the
logs
and
the
bulk
where
something
happens
wrong
and
you
just
everything
within
argosity
and
One
Stop
Shop
for
us.
B
The
next
use
cases
again,
as
we
mentioned
Argo
notifications,
which
provide
us
the
Gap
fills
of
the
Gap
data
for
the
monitoring
sites.
What
Cabana
doesn't
provide
us
now
we're
monitoring
with
Argo,
especially
so
our
compare
said
because
we
noticed
that
sometimes
Argos
under
proficient
is
not
keeping
up
with
all
the
changes.
So
we
were
able
to
notice
with
everything
within
Argo
notifications,
and
so
these
are
some
of
the
use
cases
that
that
we
have
within
elastic.
B
Also,
we
have
f
a
process
which,
whereby,
on
a
weekly
basis,
each
team
provides
a
feedback
or
an
overview
of
what
has
happened
over
the
week.
It's
not
four
numbers
for
a
sec,
but
from
all
teams
with
10
of
a
sec
which
provides
again
the
full
transparency
that
we
work
with
an
elastic
and
over
the
weeks
that
we've
been
mentioning
Argo
sidiago
events,
one
of
the
one
of
the
biggest
teams
within
elastic,
which
is
the
cloud
engineering
started
to
reach
out
to
us,
hey
folks.
B
What
do
you
think
about
Argo
Argo
CD,
how
to
implement
it
Etc
and
over
this
collaboration
within
the
two
different
teams
and
other
teams
within
a
lot
of
Crystal
elastic?
We
started
the
argosity
project,
good,
which
is
an
internalized
Community,
where,
on
a
monthly
basis
we
meet
up.
We
should
ideas,
we
share
knowledge.
We
share
what
we've
done,
what
we're
doing
and
feedback
to
expand
our
knowledge
internally
within
based
on
electricity
and
the
specific
Cloud
which
have
a
much
bigger
road
map
on
their
on
their
release,
to
expand
the
Argo.
A
Yeah,
so
that's
Chris
Chris
mentioned
Illustrated
part
of
the
cloud
security
team,
they're
gonna
start
leverages
and
they
have
a
lot
more
infrastructure
to
deal
with
than
we
do
so
it'll
be
good
to
get
their
ideas
and
how
they're
using
it
so
that
that
is
going
to
be
part
of
our
future
roadmap
of
kind
of
working
together,
understanding
how
they're
using
Argo
and
continue
to
leverage
those
use
cases.
But
anyone
familiar
with
kubernetes
probably
knows
that
secrets
are
not
necessarily
the
the
easiest
to
manage.
A
A
We
have
other
use
cases
that
we're
going
to
start
using
argo4,
so
we're
going
to
continue
building
on
that
and
I
think,
most
importantly,
once
we
do
additional
testing
and
have
a
comfort
up
on
automatically
doing
syncs
we're
going
to
enable
that
and
make
sure
we
have
the
monitoring
to
catch
any
issues
and
tie
it
back
to
our
soft
healing
infrastructure.
If
there
are
issues,
hopefully
we
can
have
Argo
remediate
those
issues
and
I
think
the
big
win
for
us,
too,
is
our
communities
and
great.
A
When
we're
building
some
centuries,
we
had
folks
chime
in
and
give
us
some
support.
You
know
immediate
support,
so
kind
of.
Thank
you,
everyone
enough
for
that
and
I'm
hoping
that
we
can
keep
that
going
and
continue
to
contribute
so
join
the
channel,
raise
issues
and
submit
PRS.
You
know,
let's
make
Argo
6
successful
because
it
surely
has
made
us
successful,
we're
very
thankful
for
that,
but
yeah.
It's
the
completes
our
session.