►
From YouTube: SIG Instrumentation 20200514
Description
SIG Instrumentation Meeting for May 14th 2020.
A
A
C
So
the
problem
which
we
want
to
solve
is
the
problem
of
sensitive
data
like
tokens
or
security
keys
or
passwords
leaking
into
control,
plane
logs-
and
this
has
been
pointed
out
as
one
of
the
points
which
require
fixing
from
the
security
audit
done
for
the
kubernetes
and
the
way
which
we
propose
to
address.
This
problem
is
to
add.
C
Some
metadata
in
the
code,
in
the
form
of
go
lonk
tags
which
could
be
detected
at
runtime
in
the
logging
library
and
if
another
arguments
passed
as
arguments
to
log
messages
contains
enough
of
the
proposed
tax.
Such
log
message
would
be
like
dropped
and
and
the
information
that
something
which
is
not
safe.
C
C
C
A
So
that
all
sounds
good
to
me
and
I
liked
the
issue
that
you
had
filed
in
the
chat
as
well
I'm,
curious,
so
I
guess
in
our
last
meeting
this
was
like
sort
of
a
draft.
There
was
not
yet
an
actual
cap.
There
is
now
a
cap
up
for
what
I
can
see.
No
one's
had
a
chance
to
review
it.
Yet
so
is
your
goal
to
target
this
for
119
in
alpha
status
or
what'swhat's.
The
timeline
for
this
sort
of
thing.
C
D
C
C
D
E
A
E
B
C
C
In
general,
this
this
is
one
of
the
ways
the
the
safety
of
the
logs
can
be
improved,
and
it's
not
that
this
is
the
only
solution
we
we
want
to
apply
about
the
in
near
future.
We
want
also
to
propose
the
other
cap
with
just
in
which
the
same
metadata
auditing
the
code
could
be
used
to
run
some
static
code.
Analysis,
yes,
actually
almost
makes
more
sense
right.
C
F
F
C
Not
because
we
we
cannot
like
analyze
all
the
paths
in
the
code
which
could
be
used
to
log
something
so
so
the
static
code
code
analyzes,
has
some
limitations
and
we
believe
that
we
should
have
like
both
solutions
in
place
do
to
improve
that
performance.
So
so
it's
not
not
really
an
alternative,
but
a
complementary
solution.
D
C
D
F
F
D
A
My
question
is-
and
this
might
be
a
little
naive
if
we
are
able
to
figure
out
what
we
should
redact
in
a
dynamic
case.
Why
can
we
not
use
that
logic
to
figure
it
out
in
the
static
case
like
if
we're
doing
a
you
know
an
interface
traversal
like?
Is
it
impossible?
We
should
be
able
to
figure
out
like
what's
going
into
that
thing.
D
D
F
A
F
Am
curious,
like
did
you
link
the
exact
report
from
the
here
53
and
I
think
this
was
accurate,
53
security
report
right
yeah
like
like
is
it?
Was
it
random,
random,
logs?
Let's
say
or
was
it
stuff
like
when
you
put
foot
verbosity
up
to
like
10
I,
think
it
is
that
you
get
like
the
entire
HTTP
request
print
it
out
and
was
that
no.
F
I
see
I
tend
to
agree.
I
would
I
would
love
to
see
how
far
we
can
get
with
static
analysis
first
I
think
and
if
we
truly
like
I
would
also
want
to
see
how
often
we
do
the
interface
passing
as
we
described
it,
maybe
maybe
you're.
Maybe
we
absolutely
do
need
it,
but
I
feel
like
trying
to
do
all
this
up
front
and
not
at
runtime
sounds
like
the
natural
first
step,
and
then
we
can
do
stuff
at
runtime.
It's
just
money.
Okay,
so.
A
A
A
D
A
C
A
E
A
C
I
imagined
I
wouldn't
consider
static
analysis
as
an
alternative,
because,
as
I
mentioned,
based
on
the
experience
which
we
have
internally
with
a
similar
solution
like
static
analysis,
finds
some
percentage
of
the
problems,
and
on
top
of
this
there
there
are
some
cases
which
which
cannot
be.
We
like
found
this
way
and
then
then
there's
runtime
verification
also
needed
so.
C
In
Indiana,
I
believe
that
we
should
have
both
and
and
those
should
use
the
same
metadata.
So
so
for
me,
it's
rather
the
question
about
the
order
in
which
we
would
like
to
implement
it
and,
as
like
the
front
and
verification
provides
higher
level
of
security.
I
I,
don't
see
why
we
cannot
go
with
with
it.
First.
F
I
mean
I
think
if
that,
if
that's
what's
required
for
us
to
get
benchmarks
about
this
I
think
I
can
and
then
we
decide
on
it.
I
can
I
think
I
could
live
with
that,
but
if
we
can
get
benchmarks
as
David
asked
even
before
that,
that
would
be
ideal,
but
yeah
I,
don't
know
I
I
think
I
think
I
could
live
with
it
as
an
alpha
thing
as
well,
and
then
we
can
reevaluate.