Tim,
Great questions. I feel like I should of expanded a bit more on what a
“secret” might be after I sent that off….
To me, a secret is something you don’t want anyone to know - that being
said, the best approach for looking at “secrets” might be to think as
restrictively as possible.
For the secrets to be any use, the units need to be able to get access to
the information right?
Sure, an example:
A web application needs creds (secrets) in order to access a 3rd party api.
These creds need to exist in a config file on the webserver/instance. As a
user, you/I know what the secrets are, but now we need to share them with
the web application, and only the web application in order for the webapp
to connect to the 3rd party api.
Who are we hiding the information from?
Considering the above example, restricting access to the “secrets” from any
entity outside of the one that would need access to them to provision them
seems like a reasonable approach. That being said, I feel like access
restrictions should be at the charm/layer level.
Two possibilities I’ve thought of:
A) Layer Sensitive Secrets - I’m thinking a secret might only be readable
to the layer in which it is configured to be used. A secret could be
context sensitive to the :, such that when you set a secret in a model, you
are setting it such that it can only be accessed by a named layer in named
charm.
B) Shared Model Secrets - Less restrictive “secrets”, accessible globally,
at the model level.
Are we hiding information from the Juju users?
When a secret is set, it could be hashed before being stored in the
database, then other users who are members of the same model wouldn’t be
able to see what the secret was, but they could see that it exists by
listing secrets.
Are we trying to hide information from other processes on the same machines
as the agents?
I think the process isolation would come along for the ride inherently as
long as processes and directories have their permissions locked down
appropriately upon setup/configuration.
Also, who generates and holds the keys?
Here’s what I’m thinking, consider the following hypothetical situation:
You basically want an action to do the following:
sudo htpasswd -c /etc/nginx/htpasswd.users kibanaadmin
Cloud admin of company X runs a Kibana instance that he desires to enhance
access control on. Kibana is deployed via Juju. Seeing as Juju “secrets”
exist, the cloud admin of company X can use the Juju CLI to set the users
and passwords (secrets) of those he desires to grant access to the Kibana
dashboard. The cloud admin wants to define the “secrets” in a .yaml file,
and feed it to his Juju environment using the juju add-secrets command,
after which he will trigger an “action” to write out the htpasswd file with
the latest secrets associated with the environment. After running juju
add-secrets, Juju hashes the secret values and stores them in the model
context of the controller, only to be unencrypted (or read) upon a call to
their getter function, called by the layer or charm whom they are
configured to in secrets.yaml. e.g.
1.
secrets.yaml
secrets:
kibana:
htpasswd-user: someuser
htpasswd-pass: somepassword
2.
juju add-secret lxd-dev-controller:my-lxd-model -f secrets.yaml
3. rm secrets.yaml
4. juju run-action kibana/0 htpasswd access='allow'
On #1 the user defines the secrets for the controller:model:charm in the
secrets.yaml.
On #2 the user updates the controller with the secrets to the
controller:model:charm, juju hashes the secrets and stores them in the
model context of the controller.
On #3 the user deletes the secrets.yaml file as he want to ensure no one
will be able to view the secrets if access is breached on his local machine.
On #4 the user runs an action that decrypts the secrets stored in the state
server, and puts them in the .htaccess file on the server.
Starting to feel like I am rambling. Hopefully this will help clarify what
I am thinking a "secret" might be!
Thoughts?
On Sun, Jul 24, 2016 at 1:53 PM, Tim Penhey <tim.pen...@canonical.com>
wrote:
On 25/07/16 06:32, James Beedy wrote:
>
>> Proposed Solution: Juju Secrets
>>
>> To give Juju a combative edge on the privacy pinwheel of secrets
>> distribution in the realm of bleeding edge devops tooling, behold my
>> hypothetical proposed solution: |juju secrets|.
>> Juju secrets could be used like so:
>> |juju add-secret mycloud:mymodel -f secrets.yaml|
>>
>> I know you guys are pressing hard to get 2.0 out the door, so please
>> don’t mind my nonsense here. I just wanted to throw the idea out there
>> and possibly get some feedback, and have others weigh in on this topic.
>>
>> Thoughts?
>>
>
> Interesting idea. How would this really work in practice?
>
> For the secrets to be any use, the units need to be able to get access to
> the information right?
>
> Who are we hiding the information from? This is always a key question that
> needs to be answered in order to choose a good solution.
>
> Are we hiding information from the Juju users?
>
> Are we trying to hide information from other processes on the same
> machines as the agents?
>
> Also, who generates and holds the keys?
>
> Just some more questions.
>
>
> Tim
>
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
