Using secrets for Datadog chart

[mazzy89]

This is my state file for Datadog Chart:

name: datadog
release:
  chart: stable/datadog:0.3.0
  version: 0.3.0
configuration:
  # Default values for datadog.
  image:
    repository: datadog/docker-dd-agent
    tag: latest
    pullPolicy: IfNotPresent

  datadog:
    ## You'll need to set this to your Datadog API key before the agent will run.
    ## ref: https://app.datadoghq.com/account/settings#agent/kubernetes
    ##
    apiKey: ""

    ## Set logging verbosity.
    ## ref: https://github.com/DataDog/docker-dd-agent#environment-variables
    ##
    logLevel: WARNING

  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 256m
      memory: 512Mi
secrets:
  - api-key

and this is how run landscraper

API_KEY=343242342342  landscaper apply --dir charts --dry-run --namespace default

Unfortunately the secret API_KEY is not applied. Any idea?

[philipbjorge]

So it seems like landscaper's method of handling secrets is not typically compatible with publicly available charts. Public charts create and reference their own secrets.

It seems to me like landscaper would benefit from an ability to load secrets into values. @rollulus -- Do you have any thoughts on this?

In the short term, I think our team is going to template in secrets into the values section during CI. https://github.com/nextrevision/sempl

[rollulus]

AFAIK there is not a standardized common way to deal with secrets in Charts.

What the Datadog chart is doing is creating a secret object and plugging in a value.

What landscaper does for its secrets is create a secret object, plug secrets from environment variables into it. A chart that uses this does not create a secret object itself from values, but rely on that externally provided secret object.

And yes, these two approaches overlap and are incompatible with each other.

But say that one would put secrets in values, as the datadog chart expects, then the secret can be read with a simple helm get, making it not so secret anymore, right? Or am I missing something?

[philipbjorge]

@rollulus -- Yes, it will appear via helm get as a user supplied value.

helm get sysdig-monitoring
REVISION: 1
RELEASED: Wed May 31 18:45:29 2017
CHART: sysdig-0.2.0
USER-SUPPLIED VALUES:
sysdig:
  AccessKey: <My Key>

This seems to be the standard approach for all the public helm charts. I'll create an issue today against the charts repo to understand their rationale.

Related issue: https://github.com/kubernetes/helm/issues/2196

Your approach definitely is more secure. Does it handle helm release rollbacks properly?

Using something like sempl seems like a decent workaround for our team in the meantime, rather than forking public charts.

[rollulus]

Interesting. To be honest, I have no clue about helm release rollbacks at all, sorry.