[
https://issues.apache.org/jira/browse/KNOX-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13844681#comment-13844681
]
Larry McCay commented on KNOX-105:
----------------------------------
It would require the agent shelling out to the CLI - which is the sort of
thing that makes me wish it were more separated from the gateway runtime
and config.
Yes, I assumed general crud type activities - though not sure about being
able to view the passwords themselves.
If someone got a hold of the master password they could easily use the CLI
to harvest all the passwords.
Maybe owning the master is bad enough but if we can try and make the
usefulness of owning it as minimal as possible that would be good.
I've considered this as a first pass and think that it would get us what we
need.
The danger is the slippery slope of having the entire server at your
disposal - if we constrain what is done then we can prune it out separately
later.
As I've mentioned separately, there may be an alternative to this tooling
in reading annotated clear text passwords on first deployment and rewriting
them as aliases with entries added to the deployed topology's credential
store.
thus:
<param>
<name>password.paramater.name</name>
<value>@supersecretpassword@</value>
</param>
yeilds:
<param>
<name>password.paramater.name</name>
<value>${ALIAS=password.paramater.name}</value>
</param>
of course, this approach is only meaningful for passwords that are also
config elements.
It could probably be argued that any password that must be known should be
a config element.
This is apposed to passwords that can be generated at deployment time and
don't need to actually match something external. Like passwords used to
generate keys, etc. They can just be requested of CMF by the consuming
provider and accessed via the known alias - no config element needed.
> Command line tooling for CMF provisioning
> -----------------------------------------
>
> Key: KNOX-105
> URL: https://issues.apache.org/jira/browse/KNOX-105
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Affects Versions: 0.3.0
> Reporter: Larry McCay
> Assignee: Larry McCay
> Fix For: 0.4.0
>
>
> We need to be able to create CMF artifacts that can be provisioned to an
> installation and discovered on startup. This will include: master secret
> file, credential and key stores. Initial deliverable needs to address master
> file. This will allow cluster provisioning to discover a master secret
> without a need for a console for the user to provide one. The rest of the
> artifacts can be generated at runtime for dev/test environments.
> Subsequently, we will need the key and credential stores for production
> environment discovery.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
