On Tue, Dec 10, 2013 at 3:48 PM, Kevin Minder (JIRA) <[email protected]>wrote:
> > [ > https://issues.apache.org/jira/browse/KNOX-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13844651#comment-13844651] > > Kevin Minder commented on KNOX-105: > ----------------------------------- > > Questions: > 1) How would this be done via something like Ambari? > 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. > 2) What is the envisioned set of required commands (e.g. add-alias, > list-alias, rm-alias, etc?). > 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. > 3) My initial reaction is to just use java -jar gateway.jar --add-alias > ... That would probably imply --nostart. What would be wrong with that? > > 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) >
