Add settings security to Maven build

[haanhvu]

Release Note

feat(build): Add settings security to Maven build

fixes #2747

My idea of the fix is to enable spec.build.maven.settings to have multiple configMapKeyRef. For example:

spec:
  build:
    maven:
     settings:
        - configMapKeyRef:
            key: settings.xml
            name: maven-settings
        - configMapKeyRef:
            key: settings-security.xml
            name: maven-settings

@squakez can you check if this is the right direction? This is not done yet. But at first I need to know if this is the right direction.

[squakez]

I think the correct way to proceed would be to have:

spec:
  build:
    maven:
     settings:
        - configMapKeyRef:
            key: settings.xml
            name: maven-settings
     settingsSecurity:
        - secretKeyRef:
            key: settings-security.xml
            name: maven-settings-security

We need to put in place what is described in https://maven.apache.org/guides/mini/guide-encryption.html and/or allowing the final user to provide such settings-security.xml during installation phase.

[haanhvu]

@squakez

     settings:
        - configMapKeyRef:
            key: settings.xml
            name: maven-settings

So you agree that we should turn configMapKeyRef to array type? Because currently I see that the type of configMapKeyRef is object.

     settingsSecurity:
        - secretKeyRef:
            key: settings-security.xml
            name: maven-settings-security

Here you mean we should turn secretKeyRef to array type too?
For now we don't have settingsSecurity yet, right?

[squakez]

That's correct. We don't have the settingsSecurity. I think this is the first thing to address.

[haanhvu]

That's correct. We don't have the settingsSecurity. I think this is the first thing to address.

@squakez I added settingsSecurity to MavenSpec. Can you check please?

[squakez]

@haanhvu that's a good start. I guess we need to develop the related logic and make use of that settings during the build now. I suggest a TDD approach, where you develop a test (similar to this https://github.com/apache/camel-k/blob/main/pkg/builder/project_test.go#L193) and then you complete the logic to pass that test.

[haanhvu]

@haanhvu that's a good start. I guess we need to develop the related logic and make use of that settings during the build now. I suggest a TDD approach, where you develop a test (similar to this https://github.com/apache/camel-k/blob/main/pkg/builder/project_test.go#L193) and then you complete the logic to pass that test.

@squakez From my understanding, we need to test settingsSecurity together with settings. There's no point testing settingsSecurity alone, right?

[haanhvu]

@squakez can you pls check the test cases?

[squakez]

The unit test looks okey. I think you must now develop the logic to make use of that settings. You can make reference to the implementation done for settings as well, see https://github.com/apache/camel-k/blob/main/pkg/builder/project.go#L107

[haanhvu]

@squakez could you help me a little here:

From my understanding, in the logic there's a step to encrypt server passwords with the command line mvn --encrypt-password

How can I implement this step in the code?

[squakez]

@squakez could you help me a little here:

From my understanding, in the logic there's a step to encrypt server passwords with the command line mvn --encrypt-password

How can I implement this step in the code?

So, that step must be performed manually by the user which ends up with this file: ${user.home}/.m2/settings-security.xml. The user must create a secret (or configmap) and then reference into the IntegrationPlatform maven specification. We don't have to do much there. What we need to do is to use that information when we build the project, similarly of what we already do when we use customized settings.xml. Hope this clarifies.

[haanhvu]

@squakez I understand that the user needs to create a master password manually. What you just described is this:

What I asked is about encrypting server password:

From what I read in https://maven.apache.org/guides/mini/guide-encryption.html , once we have the settings-security.xml file, we need to encrypt the server password with mvn --encrypt-password and inject the encrypted password into the server tag in settings.xml (like the second screenshot). And I thought we need to implement this in the build? That's why I asked how to implement the command line mvn --encrypt-password in the code.

[squakez]

@haanhvu that link was there just to illustrate the reason why the feature is meant to be. We need to focus on passing whatever the settings-security.xml contains to the maven project used by the build.

[haanhvu]

@haanhvu that link was there just to illustrate the reason why the feature is meant to be. We need to focus on passing whatever the settings-security.xml contains to the maven project used by the build.

@squakez I did this. Could you pls review if I did it right?

[squakez]

I think it's okey. It would be good to have an E2E test however, in order to confirm that we really use those settings-security correctly when provided. Do you think can you try? alternatively you may create an example in the example directory which we can use as a tester for this new feature.

[haanhvu]

@squakez e2e test seems to be a better idea. I'll give it a try.

[haanhvu]

I think it's okey. It would be good to have an E2E test however, in order to confirm that we really use those settings-security correctly when provided. Do you think can you try? alternatively you may create an example in the example directory which we can use as a tester for this new feature.

@squakez Could you guide me a little here? We need to add a test case to an existing test, a create a whole new test? Do we have a similar test for settings already?

[squakez]

@haanhvu we probably need a new test. You can use the tests in this directory as a reference https://github.com/apache/camel-k/tree/main/e2e/common/build as they are all dealing with maven configuration. Feel free to create a new file which contains your set of test (if you can take the opportunity and provide the settings, it would be very welcome). In order to execute them locally, please, have a look at the guide to perform E2E locally.

If you need any further support, don't hesitate to ask.

[haanhvu]

It looks like a Golang project setting issue. The action you're doing is always calling a make controller-gen which should take care to install that binary in your environment. Can you try running only make controller-gen and check if a binary is installed in the $(go env GOPATH)/bin directory?

@squakez make controller-gen runs without error but no binary is installed in bin directory.

I guess the bin directory might not be set up correctly when I installed go. Could you suggest what to do to reset up the bin directory? I followed some commands from google but they didn't work.

[squakez]

@haanhvu can you try to execute go env? You may check what is your GOPATH

[haanhvu]

@squakez I fixed the problem with make generate. Turned out the problem is that controller-gen doesn't support go 1.18 yet, so I downgraded to go 1.17.9 and it worked.

I ran make generate, then make, then make build-kamel. I didn't set up the operator locally but ran make install-minikube (with no previous Camel K instance installed). All the commands ran successfully.

However in the end kubectl still doesn't know about the new settingsSecurity:

$ minikube kubectl -- apply -f ip.yaml
error: error validating "ip.yaml": error validating data: ValidationError(IntegrationPlatform.spec.build.maven): unknown field "settingsSecurity" in org.apache.camel.v1.IntegrationPlatform.spec.build.maven; if you choose to ignore these errors, turn validation off with --validate=false

I pushed the generated changes from make generate here. Can you check if there's anything wrong with them?

Or is there a problem with my ip.yaml?:

apiVersion: camel.apache.org/v1
kind: IntegrationPlatform
metadata:
  name: camel-k
spec:
  build:
    maven:
      settings:
        configMapKeyRef:
          key: settings.xml
          name: maven-settings
      settingsSecurity:
        configMapKeyRef:
          key: settings-security.xml
          name: maven-settings-security

Also, as I said, I use the go version 1.17.9. Is it a recommended version for camel-k?

[squakez]

The Golang version we support is actually 1.16. As for the Custom Resource, probably it's because you still have some reference to the previous installation. Ideally you should delete all Custom Resources (ie, via kamel uninstall --all -olm=false). Later you need to use your local CLI to install the CRDs (ie, this change you're adding in this PR). You can do that running ./kamel install --skip-operator-setup --olm=false. This command should set the new CRDs accordingly.

[haanhvu]

The Golang version we support is actually 1.16. As for the Custom Resource, probably it's because you still have some reference to the previous installation. Ideally you should delete all Custom Resources (ie, via kamel uninstall --all -olm=false). Later you need to use your local CLI to install the CRDs (ie, this change you're adding in this PR). You can do that running ./kamel install --skip-operator-setup --olm=false. This command should set the new CRDs accordingly.

@squakez I uninstalled camel-k. I knew it's uninstalled because when I checked with kubectl -- api-resources, no custom resources related to camel-k were there.

Then I reinstalled with ./kamel install --skip-operator-setup --olm=false as you said. Checked again with kubectl -- api-resources and camel-k custom resources appeared.

However, the settingsSecurity was still not there:

$ minikube kubectl -- apply -f ip.yaml
error: error validating "ip.yaml": error validating data: ValidationError(IntegrationPlatform.spec.build.maven): unknown field "settingsSecurity" in org.apache.camel.v1.IntegrationPlatform.spec.build.maven; if you choose to ignore these errors, turn validation off with --validate=false

I highly suspect this is a golang version problem again during build. Should I downgrade to go 1.16.x? I read in #3236 that some make commands may not work correctly with go 1.16.x

[squakez]

Hi @haanhvu I think here it is complaining about not correctly installed CRDS. Can you run the following and get the output:

kubectl get crd integrationplatforms.camel.apache.org -o yaml | grep settings

What we need to do is to install the proper CRDs into the cluster in order to have your changes applied. As a last resort, if the above does not show any settingsSecurity you can install the CRDs you can find in your local config/crd/bases/ manually.

[haanhvu]

Hi @haanhvu I think here it is complaining about not correctly installed CRDS. Can you run the following and get the output:

kubectl get crd integrationplatforms.camel.apache.org -o yaml | grep settings

What we need to do is to install the proper CRDs into the cluster in order to have your changes applied. As a last resort, if the above does not show any settingsSecurity you can install the CRDs you can find in your local config/crd/bases/ manually.

@squakez yeah manually install the crd could be the last simple choice. I just wanted to inspect if my environment has any problems with the build and the install. Anyway I'll dive deeper into this later...

I set up the crd manually and it worked:

minikube kubectl -- get crd integrationplatforms.camel.apache.org -o yaml | grep settings
                      settings:
                          contains the Maven settings.
                      settingsSecurity:
                          contains the security of the Maven settings.
                      settings:
                          contains the Maven settings.
                      settingsSecurity:
                          contains the security of the Maven settings.

minikube kubectl -- apply -f ip.yaml
Warning: resource integrationplatforms/camel-k is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
integrationplatform.camel.apache.org/camel-k configured

minikube kubectl -- get integrationplatforms
NAME      PHASE
camel-k

Should I add this example to the PR and we get this done now? I'll add the e2e test in a later PR.

[squakez]

Should I add this example to the PR and we get this done now? I'll add the e2e test in a later PR.

Yes please. Provide a detailed example on how to use the new configuration.

[haanhvu]

Should I add this example to the PR and we get this done now? I'll add the e2e test in a later PR.

Yes please. Provide a detailed example on how to use the new configuration.

@squakez I added an example and also edit the maven doc. Please check if those work

[squakez]

+1 for the documentation update. However, I'd have a separate section nested under == Maven Settings called === Security Settings. In there you may link also to the Maven website which explain how to setup the security settings file

[squakez]

Good. Let's move it under /examples/maven. user-config directory was thought for kamel run parameters.

[squakez]

Where is this servers coming from?

[haanhvu]

@squakez it was generated from make generate

[squakez]

yes, can you regenerate? it looks like it was picking that from source, ie, maven_types.go

[haanhvu]

@squakez ok I will.

In fact there're other generated things that's not related to my PR. For example, this

I guess they belong to some previous PRs which forgot to generate them?

[squakez]

it may happen, yes. Make sure to rebase with the latest from main, so you will get the freshest things.

[haanhvu]

@squakez I regenerated and nothing's changed.

Also moved the maven example directory and updated the maven doc properly.

[haanhvu]

@squakez A few updates:

I just rebased with the latest main then ran make. The make command generated a few things in resources.go. Can you check my latest commit to see if it's normal?

I don't know if it's thanks to the new genarated or not. But the new change is now successfully installed and I don't need manually install the crd anymore.

It runs well:

I also moved the example directory and updated the doc.

Could you review?

[squakez]

Merged. Thanks for the contribution!