maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alix Lourme <alix.lou...@gmail.com>
Subject Re: Maven password encryption by project
Date Sat, 18 Mar 2017 16:16:03 GMT
Hi Jim,

Thanks for your feedback, my answer in the text.

2017-03-17 21:51 GMT+01:00 Jim Klo <jim.klo@sri.com>:

> As others have mentioned, you shouldn’t be storing passwords in a POM.
>

Fully agree :)


>
> I as well don’t have a great corporate solution that works for secrets
> management for maven.
>
> My solution has been to use Environment Variables - which basically
> follows the same pattern that AWS, Docker, Vagrant and others utilize.
> The pattern requires you to define a convention so that your secret is
> set into a predictable environment variable from which you can then use
> within your POM, script, etc while the job is running.
>
> As far as for local users - generally this can be a one time setup, then
> from there you don’t need to monkey with credentials ever again until you
> have to cycle. You shouldn’t need to share any credentials.
>
> This works well because unless you echo the environment, secret info isn’t
> echoed into the logs. And it can be utilized for non-secret information as
> well.
>

I agree environment variables could be a sustainable solution.

But for "local" builds (developers who works on own machine) it could be a
little tricky when they work on many projects: you should know & configure
some/many environment variables before the project build after checkout.

In a company, in could be hard to deploy a process like that based on some
"convention name" (on some environment variable).
The precept of "checkout, build ... it should works" is important to kept.

Currently, we have deploy a system of private key "by project" (=>
generally the development team perimeter, who work on one or some Maven
projects).
It allow to encrypt some credentials (technical account, tokens, ... used
in project build like application server deployment), decrypted as Maven
properties during build.
So the prerequisite of concept of "checkout, build ... it works" is just to
have the private key of this project perimeter.

This process has some inconvenients (sharing some credentials like Charles
said, specificity on CI agents for this private key availability, ...),
requires some dedicated plugin (inherited from pom company), but it does
the job since 10 years: give a minimal security level, simple to use.

My wish is today to switch on the best practices for that (credentials
encryption), but keeping the simplicity of usage (among few hundred
developers; the level of Maven mastery is not the same for all).


>
> On Mar 17, 2017, at 6:38 AM, Alix Lourme <alix.lourme@gmail.com> wrote:
>
> I'm searching the best practice for password encryption in a maven POM
> file *by
> project*, could by used by properties (like in ANT or WAGON). Sample :
> ---
> <plugin>
>    <artifactId>maven-antrun-plugin</artifactId>
>    <version>1.8</version>
>    <configuration>
>        <target>
>            <echo message="Get docker certificates" />
>            <mkdir dir="cert" />
>            <scp file="root:${docker.password}@10.xx.xx.xx:/root/.docker/*"
> todir="cert" trust="yes" />
>        </target>
>    </configuration>
> </plugin>
> ---
>
> In this case, my *docker.password* could be a properties (pom or
> settings.xml) but must not be in clear text.
>
>
> Is there a reason you’ve not using an identity file instead for this
> situation? It would likely work better, and you could pass the identity
> file as a secret file, from a separate system, repository, or local
> configuration for running the build.
>

It was just a snippet to explicit the problem.

Many various Maven plugins or configuration requires user/password
configuration, who should provided by Maven property but not in pom (=>
with settings.xml, environment variable, or other process like specific
plugin explained previously); and it is better if this property is not
written in clear text in any files.


>
>
> The problem with Maven encryption
> <https://maven.apache.org/guides/mini/guide-encryption.html>:
> - I have a master password defined in *settings-security.xml* (locally) for
> my user need (like proxy password encryption in MY *settings.xml*)
> - The CI tools contains the same mechanism (own *settings-security.xml*)
> for global needs, like server encryption used in *settings.xml* for jar
> publication in repository ; and I can't retrieve this file
>
>
> AFAIK maven encryption only applies to <server> elements.  Others can
> chime in, but not sure that this would solve your specific problem anyways.
> Does your CI solution have some kind of mechanism for retrieving or
> providing secret information/files?  This seems to be the root of your
> problem.
>

Maven encryption works for all properties in settings.
CI platform have some "global" credentials to facilitate/promote the usage
of (exemple) Maven website publication, SonarQube analysis.
I agree it could be considered as evil, but this solution allows:
- To deploy massively some process (doc, quality, ...) for all projects.
- The CI platform keeps the capacity to have special credentials to deploy
some jobs on central tools

The solution could be that all project provides own settings-security.xml &
settings at build ... but I fear this way could be to difficult for some
people and reduce the usage of recommended process (doc, quality, ...); and
*special* credentials of CI is lost in this case.



>
>
> => I can't use this mechanism for password encryption who works locally and
> on the CI server.
>
> *Is there a way to have a encryption mechanism for the project's perimeter
> ?* (and not for user's perimeter, current Maven encryption works perfectly
> for that).
>
>
> Environment variables can solve that, but not sure why you would want
> project level vs user level credentials.
>
>
> Using -s and -gs Maven options (=> user/global settings override) could be
> a workaround but :
> - Server item definition or properties defining password must be in clear
> text
> - Using this Maven settings for each build depending the project workspace
> is a little boring
>
>
> Why do you want something not boring?… usually means something that should
> always work doesn’t….
>
> CI systems usually invoke with -s and -gs anyways, so I’m not sure what
> the big deal is.
>
> The way I’ve handled this is defaults use the ~/.m2/settings.xml and the
> CI utilizes a -s flag with a provided file.
>

I want a way where "mvn install" works locally and on CI everytime, on all
projects, without providing additional files, properties, configurations
... except perhaps only one item :).


>
>
> Perhaps is there a best way like a "private key by project" ... but I
> didn't found entry point about that.
>
>
> I’m still not entirely sure what you mean by “per project”.  Do you mean
> “per module”?
> If you’re having to have multiple credentials for a single project/reactor
> build, It’s possible that you’re problem is your CI Job is not granular
> enough.
>

I mean by project = a Maven autonom component (proper lifecycle). But it is
more in fact by "development team perimeter" (=> some limited Maven
projects).
When you integrate a new developer in team, he should knows some/many
technical accounts or tokens used for project builds, mainly on CI (SCM
release, staging server for deployment, ...).

The idea is avoiding the unitary configuration of each credentials
somewhere by all developer, to facilitate starting the work on project.

Having just a private key or knowing a "master" password/secret by project
is IMO more simple.


>
> Thanks in advance. Best regards
> *NB*: This question was firstly on stackoverflow
> <https://stackoverflow.com/questions/33784790/maven-
> password-encryption-by-project>,
> but no really interest ^^.
>
>
> SO question doesn’t exist - that might be why there’s no interest?
>

The link exists but question status is RemoveAbandonedQuestions
<https://stackoverflow.com/help/roomba>, so some *undelete* action is
required by 2 people with high reputation
<https://meta.stackexchange.com/questions/5221/how-does-deleting-work-what-can-cause-a-post-to-be-deleted-and-what-does-that>
for reappearance (this is a *request for click* ^^)

Best regards.
-- 
Alix Lourme

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message