Support SECRETS as requirement type

[jberkus]

We need to have a way in the spec to offer support for Secrets. In the case of Docker, this would be ENV variables passed by a file, or something. For Kubernetes, this would be a Secrets mount.

[goern]

Could you give us the user story this requirement comes from?

Principal Software Engineer - Systems Design & Engineering Mobile: +49 171 2801345

Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, Handelsregister: Amtsgericht München, HRB 153243, Geschäftsführer: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

[jberkus]

Sure, "I want to deploy a database-backed web application".

This requires two things in the way of secrets:

1. We need to share database username/passwords for the web application
2. We need to share different ones depending on the environment (test, staging, prod)

The reason to support them in Nulecule is that we want this to work even if the developer is using Docker on their desktop and ops is using Kubernetes in production. Or if the atomic.app was developed for Kubernetes but someone decides to deploy it to Mesos. Plus, the required secrets are a characteristic of the application (not the platform), and therefore belong in the nulecule file.

For that reason, we need to not only have support for secrets but we need to be able to pass them via Answers.conf.

[goern]

What is the difference between what you propose and the use of parameters and answers.conf to parameterize a deployment of an Atomic App? If you have a look at https://github.com/projectatomic/nulecule-library/blob/master/wordpress-centos7-atomicapp/Nulecule#L17 you see the db_user and db_pass parameters that could be used to parameterize the mariadb database backend used by the wordpress web frontend.

[jberkus]

The main issue is that Secrets generally contain stuff which you don't want going into a poorly secured source code repo (or even a public one), the way answers.conf generally do. Such as database passwords.

That's why we have Kubernetes secrets, Vault, and similar technologies.

[goern]

Understood, I think you exactly mentioned the reason why secrets are not within a Nulecule file (because it is public, as part of the container image) and why answers.conf should not be on a public repo (as it may contain environment specific corporate confidential information).

From my point of view the way to go it:

1. declare a parameter in the Nulecule file, so that the deployment guy knows which parameters are required
2. distribute the Atomic App without any secrets
3. parameterize a deployment, so that the parameters have values valid for the current deployment for the specific environment (aka. provide an answers.conf)
4. deploy

I really dont see why you want to put a username/password in step 2.

[jberkus]

@goern I see what you're saying. Question is: is declaring the required params (which will be supplied by secrets) sufficient? I suppose if they are params with no defaults, that makes sense.

If we're taking that tack, then this becomes an implementation issue for atomic.app

[goern]

Ja, think so. But I would say, that 'the secrets (username,password) are declared within the Nulecule file, and their values need to be provided during the parameterization of the deployment'... so the last part refers to atomicapp (the deployment guy role) and the first part to the ISV/developer roles.

[jberkus]

Closing in favor of atomic.app issue.