Implement Watchers which will have long-lived connections (and reconnect when dropped) to the Kubernetes/OpenShift API. These watchers will monitor for

• ConfigMap[label=nexus-type==blobstore]
• ConfigMap[label=nexus-type==repository]
• Secret[name==nexus]

When new ConfigMaps are created, they will trigger the provisioning of the appropriate items (BlobStore or Repository)

When the Secret changes, the code will update the admin password.

I tried deploying the jar deliverable in a NXRM 3.17 instance and got the following error in the nexus.log in the startup process:

2019-07-15 15:29:11,942-0500 ERROR [FelixDispatchQueue] *SYSTEM com.redhat.labs.nexus.openshift-plugin - FrameworkEvent ERROR - com.redhat.labs.nexus.openshift-plugin
org.osgi.framework.BundleException: Unable to resolve com.redhat.labs.nexus.openshift-plugin [53](R 53.0): missing requirement [com.redhat.labs.nexus.openshift-plugin [53](R 53.0)] osgi.wiring.package; (&(osgi.wiring.package=io.fabric8.kubernetes.api.model)(version>=4.3.0)) Unresolved requirements: [[com.redhat.labs.nexus.openshift-plugin [53](R 53.0)] osgi.wiring.package; (&(osgi.wiring.package=io.fabric8.kubernetes.api.model)(version>=4.3.0))]
	at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4132)
	at org.apache.felix.framework.Felix.startBundle(Felix.java:2117)
	at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371)
	at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
	at java.lang.Thread.run(Thread.java:748)

I noticed that the jar is pretty small (22Kb), it doesn't have the dependencies shaded in it. I'm no expert on OSGi or karaf, but I tried to get a kar deliverable by adding the following to the pom:

     <plugin>
        <groupId>org.apache.karaf.tooling</groupId>
        <artifactId>karaf-maven-plugin</artifactId>
        <executions>
          <execution>
            <goals>
              <goal>kar</goal>
            </goals>
            <phase>package</phase>
          </execution>
        </executions>
      </plugin>

This produces a kar file with the dependencies included:

~/git/nexus-kubernetes-openshift(master ✗) ls -al target/nexus-openshift-plugin-3.17.0-01.kar
-rw-r--r--  1 nblair  staff  18342019 Jul 16 08:22 target/nexus-openshift-plugin-3.17.0-01.kar

But that still produces a similar error during startup:

WARN  [fileinstall-/Users/nblair/git/nexus-internal/target/nexus-professional-3.17.0-01/deploy] *SYSTEM org.apache.karaf.kar.internal.KarServiceImpl - Unable to install Kar feature nexus-openshift-plugin/3.17.0.01
org.osgi.service.resolver.ResolutionException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=nexus-openshift-plugin; type=karaf.feature; version="[3.17.0.01,3.17.0.01]"; filter:="(&(osgi.identity=nexus-openshift-plugin)(type=karaf.feature)(version>=3.17.0.01)(version<=3.17.0.01))" [caused by: Unable to resolve nexus-openshift-plugin/3.17.0.01: missing requirement [nexus-openshift-plugin/3.17.0.01] osgi.identity; osgi.identity=io.fabric8.openshift-client; type=osgi.bundle; version="[4.3.0,4.3.0]"; resolution:=mandatory [caused by: Unable to resolve io.fabric8.openshift-client/4.3.0: missing requirement [io.fabric8.openshift-client/4.3.0] osgi.wiring.package; filter:="(&(osgi.wiring.package=io.fabric8.kubernetes.api.builder)(version>=4.3.0)(!(version>=5.0.0)))" [caused by: Unable to resolve io.fabric8.kubernetes-model/4.3.0: missing requirement [io.fabric8.kubernetes-model/4.3.0] osgi.wiring.package; filter:="(&(osgi.wiring.package=javax.validation)(version>=2.0.0)(!(version>=3.0.0)))"]]]
	at org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)
	at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:389)
	at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375)
	at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:347)
	at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)
	at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

I'm not sure how to resolve bundling errors like this...

Need to update the field mappings in RepositoryConfigWatcher so that Nexus version information for both recipes AND fields are defined. This will then be used in new logic to help decide which recipes can and cannot be deployed on the given version of Nexus.

The plan is to inject an instance of org.sonatype.nexus.common.app.ApplicationVersion into OpenShiftConfigPlugin and pass the version value to the appropriate methods as needed. The we will use VersionComparator to filter to the appropriate versions of Nexus.

When provisioning Nuget repositories from Kubernetes ConfigMaps the BlobStore argument appears to be malfunctioning. The implementation HERE indicates that this should be a supported capability, but JUST for Nuget repositories it is not working. All other repository types seem to be provisioned correctly.

I have started a thread on the Nexus mailing list to see if we can find the root cause of this error as the Unit Tests in this project show that the methods are being called correctly but the expected result is not achieved.

https://github.com/DannyFranklin/DannyFranklin/blob/main/.github%2Fworkflows%2F%232

See here: https://sonarcloud.io/project/issues?id=com.redhat.labs.nexus%3Anexus-openshift-plugin%3A3.0&issues=AWwFG1XPwtX4DTACJUXl&open=AWwFG1XPwtX4DTACJUXl

And here: https://sonarcloud.io/project/issues?id=com.redhat.labs.nexus%3Anexus-openshift-plugin%3A3.0&issues=AWwVBqSuYvTlaYER0yyv&open=AWwVBqSuYvTlaYER0yyv

• Ensure requested blobstore exists
• Ensure that Group lists contain valid types of repositories
  • e.g. Don't allow Maven and NPM repositories to be mixed in a Group
  • Ensure that group members actually exist

My first thought on this is a single ConfigMap which has keys for each repository to indicate if it should be accessible anonymously or not. For example:

apiVersion: v1
data:
  maven-central: 'true'
  myNugetRepo: 'true'
  myDockerGroup: 'false'
kind: ConfigMap
metadata:
  name: my-blobstore
  namespace: labs-ci-cd
  labels:
    nexus-type: anonymous

The plugin would read and parse the data, and set anonymous access appropriately. IF a repository is not listed, the plugin will not modify access for that repository.

Another possibility is allowing for a default which would set all repositories to either allow or disallow anonymous access globally.

Vulnerabilities

DepShield reports that this application's usage of org.apache.commons:commons-compress:1.11 results in the following vulnerability(s):

• (CVSS 5.5) [CVE-2018-11771] Resource Management Errors
• (CVSS 5.5) [CVE-2018-1324] Resource Management Errors

Occurrences

org.apache.commons:commons-compress:1.11 is a transitive dependency introduced by the following direct dependency(s):

• io.kubernetes:client-java:5.0.0
        └─ org.apache.commons:commons-compress:1.11

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

During the user survey, 7/10 respondents wanted to be able to configure tasks from the Kubernetes/OpenShift API

Vulnerabilities

DepShield reports that this application's usage of org.apache.commons:commons-compress:1.11 results in the following vulnerability(s):

• (CVSS 5.5) [CVE-2018-11771] Resource Management Errors
• (CVSS 5.5) [CVE-2018-1324] Resource Management Errors

Occurrences

org.apache.commons:commons-compress:1.11 is a transitive dependency introduced by the following direct dependency(s):

• io.kubernetes:client-java:5.0.0
        └─ org.apache.commons:commons-compress:1.11

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Vulnerabilities

DepShield reports that this application's usage of com.fasterxml.jackson.core:jackson-databind:2.9.2 results in the following vulnerability(s):

• (CVSS 10.0) [CVE-2018-14721] FasterXML jackson-databind 2.x before 2.9.7 might allow remote attackers to cond...
• (CVSS 9.8) [CVE-2018-7489] Incomplete Blacklist, Deserialization of Untrusted Data
• (CVSS 9.8) [CVE-2018-19361] Deserialization of Untrusted Data
• (CVSS 9.8) [CVE-2017-17485] Improper Control of Generation of Code ("Code Injection")
• (CVSS 9.8) [CVE-2018-14719] Deserialization of Untrusted Data
• (CVSS 9.8) [CVE-2018-14718] Deserialization of Untrusted Data
• (CVSS 9.8) [CVE-2018-19360] Deserialization of Untrusted Data
• (CVSS 9.8) [CVE-2018-19362] Deserialization of Untrusted Data
• (CVSS 9.8) [CVE-2018-14720] Improper Restriction of XML External Entity Reference ("XXE")
• (CVSS 8.1) [CVE-2018-5968] Incomplete Blacklist, Deserialization of Untrusted Data
• (CVSS 7.5) [CVE-2018-12022] Deserialization of Untrusted Data
• (CVSS 7.5) [CVE-2018-12023] Deserialization of Untrusted Data
• (CVSS 7.5) [CVE-2019-12086] Information Exposure

Occurrences

com.fasterxml.jackson.core:jackson-databind:2.9.2 is a transitive dependency introduced by the following direct dependency(s):

• org.sonatype.nexus:nexus-plugin-api:3.17.0-01
        └─ com.fasterxml.jackson.core:jackson-databind:2.9.2

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Currently, the plugin will only allow creation of NEW repositories. IF a repository already exists, it cannot be modified by the plugin. This was a design decision to prevent updating a repository from one type to another and potentially losing data. In the case of Groups, it makes sense to be able to change the members of a group.

Vulnerabilities

DepShield reports that this application's usage of com.thoughtworks.xstream:xstream:1.4.10 results in the following vulnerability(s):

• (CVSS 7.5) [CVE-2013-7285] Improper Neutralization of Special Elements used in a Command (Command Injection)

Occurrences

com.thoughtworks.xstream:xstream:1.4.10 is a transitive dependency introduced by the following direct dependency(s):

• org.sonatype.nexus:nexus-plugin-testsupport:2.14.13-01
        └─ org.sonatype.nexus:nexus-test-common:3.17.0-01
              └─ org.sonatype.goodies:goodies-testsupport:2.3.0
                    └─ org.powermock:powermock-classloading-xstream:1.6.1
                          └─ com.thoughtworks.xstream:xstream:1.4.10

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

The root cause seems to be https://issues.sonatype.org/browse/NEXUS-25162
"Note for release:

org.sonatype.nexus.repository.storage.WritePolicy has been moved to org.sonatype.nexus.repository.config.WritePolicy.

This will impact any groovy scripts using the org.sonatype.nexus.script.plugin.RepositoryApi to create repositories. The resolution is to change any references of org.sonatype.nexus.repository.storage.WritePolicy to org.sonatype.nexus.repository.config.WritePolicy in those scripts."

From the user survey, 9/10 respondents would like to be able to use S3-compatible storage for BlobStores

In newer versions of Nexus, the Admin password is generated on the first start of the application. This means that the default admin password is no longer admin123 and as such the admin password change code no longer works on these newer versions of Nexus. Need to add code to support these newer versions of Nexus.

For Groups, the appropriate Hosted and Proxy repositories need to exist before the group can be created. Add logic to the code to have groups created AFTER Proxy and Hosted repositories.

The Dockerfile.rhel7 is using user nexus and group nexus which is not compatible with OpenShift. Need to change this to user root and group root with 775 permissions.

Nexus has a concept of "roles" and roles have various "privileges". It would be helpful to support creating/modifying/managing roles using this plugin via a declarative use of ConfigMaps or Custom Resource Definitions.

Vulnerabilities

DepShield reports that this application's usage of io.netty:netty-all:4.0.36.Final results in the following vulnerability(s):

• (CVSS 7.5) [CVE-2016-4970] handler/ssl/OpenSslEngine.java in Netty 4.0.x before 4.0.37.Final and 4.1.x befo...

Occurrences

io.netty:netty-all:4.0.36.Final is a transitive dependency introduced by the following direct dependency(s):

• org.sonatype.nexus:nexus-plugin-testsupport:2.14.13-01
        └─ org.sonatype.nexus:nexus-test-common:3.17.0-01
              └─ org.littleshoot:littleproxy:1.1.0
                    └─ io.netty:netty-all:4.0.36.Final

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Vulnerabilities

DepShield reports that this application's usage of com.google.guava:guava:21.0 results in the following vulnerability(s):

• (CVSS 5.9) [CVE-2018-10237] Deserialization of Untrusted Data

Occurrences

com.google.guava:guava:21.0 is a transitive dependency introduced by the following direct dependency(s):

• io.kubernetes:client-java:5.0.0
        └─ com.google.guava:guava:21.0

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Vulnerabilities

DepShield reports that this application's usage of com.google.guava:guava:21.0 results in the following vulnerability(s):

• (CVSS 5.9) [CVE-2018-10237] Deserialization of Untrusted Data

Occurrences

com.google.guava:guava:21.0 is a transitive dependency introduced by the following direct dependency(s):

• io.kubernetes:client-java:5.0.0
        └─ com.google.guava:guava:21.0

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Vulnerabilities

DepShield reports that this application's usage of com.squareup.okhttp3:okhttp:3.12.0 results in the following vulnerability(s):

• (CVSS 5.9) [CVE-2018-20200] ** DISPUTED ** CertificatePinner.java in OkHttp 3.x through 3.12.0 allows man-in...

Occurrences

com.squareup.okhttp3:okhttp:3.12.0 is a transitive dependency introduced by the following direct dependency(s):

• io.fabric8:openshift-client:4.3.0
        └─ io.fabric8:kubernetes-client:4.3.0
              └─ com.squareup.okhttp3:okhttp:3.12.0

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

From the user survey, 7/10 respondents use and would like to configure clean-up policies