[
https://issues.apache.org/jira/browse/MBUILDCACHE-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17628615#comment-17628615
]
Alexander Ashitkin commented on MBUILDCACHE-33:
-----------------------------------------------
It is not similar. Let's narrow down case to a build which needs secrets in a
container on Kubernetes.
* Option1: image with embedded settings.xml - no go, insecure to publish
credentials into binary repo and complicates maintenance in case of credentials
expiry
* Option2: Mount secrets.xml from a shared volume - again no go, as it
requires the same - store secrets in some 3rd storage where they could leak
* Option 3: Mount settings xml from secrets as a volume - again inconvenient
as it mixes 2 orthogonal problems - maven setup management and credentials
management. Imagine need to change mirror or add proxy. What to do? Edit
secrets?
Usage of settings xml in build environment is either insecure, either add
complexity. Moreover, any access to credentials in settings.xml at build time
is a potential security breach, as they could be easily leaked by redirecting
repository call to a sniffer. So realistically, there is no good case to keep
anything but personal credentials in settings.xml on own desktop.
Now, speaking of secure setup - the only way in managed environment to control
credentials is to use secrets service and each major cloud platform provides
some form of such a service. Usually, credentials are mounted on container
either like a volume (mainly for keys) or as env var - for individual secrets,
like password.
Now, having typical case of container securely bootstrapped with injected
secrets, there are just 2 options to use them in build:
1) Directly, as in this pr.
2) Indirectly, by resolving placeholders in config files from ${env.MY_VAR}
3) Indirectly, by setting vm flags from env vars:
-Dcache.password=${CACHE_PASSWORD}
Option 2 doesn't work in settings.xm. Even if it works it will require to store
settings.xml if build environment is shared. Option 3 increases chances to leak
credentials through logs if masked improperly or if command line is captured in
tooling.
So basically, in container environment, settings.xml is a big security leak. In
terms of convenience only env vars provide convenient and secure way to inject
credentials in build container. Though it's possible to find working solution
using one of the ways above, but again that's likely insecure or inconvenient.
Environment variable is the optimal way.
I hope it explains!
> Support remote cache credentials from environment variables
> ------------------------------------------------------------
>
> Key: MBUILDCACHE-33
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-33
> Project: Maven Build Cache Extension
> Issue Type: New Feature
> Reporter: Alexander Ashitkin
> Priority: Major
> Labels: pull-request-available
>
> In my current environment settings.xml are managed by a build team which is
> not allowing any modification because the same build service is used by all
> teams. Atop of that, maven build runs in a fresh container which doesn't have
> any credentials injected for security reasons. Because of that cache cannot
> read/deploy build artifacts to an authenticated http server. Still, our build
> service allows to inject credentials from environment variables into build
> container. Need to support cache setup without settings.xml by injecting
> environment variables:
> * MAVEN_BUILD_CACHE_DIRECT_CONNECT
> * MAVEN_BUILD_CACHE_USER
> * MAVEN_BUILD_CACHE_PASSWORD
> * MAVEN_BUILD_CACHE_PROXY_USER
> * MAVEN_BUILD_CACHE_PROXY_PASSWORD
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
