Closed jberkus closed 8 years ago
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
Sure, "I want to deploy a database-backed web application".
This requires two things in the way of secrets:
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.
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.
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.
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:
I really dont see why you want to put a username/password in step 2.
@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
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.
Closing in favor of atomic.app issue.
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.