Containerless distributions of the Kantra CLI - Java

[rromannissen]

What is the problem?

The Kantra CLI requires a container runtime to be present at the host it runs as the analyzer engine and the different language providers are spin up in containers.

Why is this a problem?

Highly regulated organizations from verticals like FSI and public agencies have very strict security policies that severely restrict the software that can be installed in corporate computers. Container runtimes are in most cases not allowed due to the fact that they would allow the user to freely run software outside of the security policies. This leads to users coming from these business vertical not being able to use the Kantra CLI, and by extension, Konveyor as a project to help them with their migration needs.

On top of that, the current approach of the Kantra CLI makes it very hard to have it integrated on CI/CD pipelines, as the requirement of having direct access to the container runtime to spin up analyzer and provider containers only allows it to run on VMs and bare metal hosts, making it incompatible with Jenkins container agents and Tekton tasks.

Proposed solution

Create self contained bundles for the CLI that package the analyzer and the provider for a given language, so they can be installed directly in the host without the need of a container runtime. The following should be taken into account when putting these bundles together:

• Requirements for the bundle to run shouldn't be too complex in terms of configuration, as users on those restricted environments normally have limited access to it. Admin permissions and privileged execution requirements must be avoided as well as users are unlikely to have access to them.
• Requirements for each bundle should be clearly documented. For example, OpenJDK will be required for the Java bundle, whereas certain .NET releases might be required for the .NET bundle.
• Windows should be the top priority for the availability of these bundles, as it is the most widespread OS in these restricted corporate environments and the one in which these restrictive policies are being applied most commonly. Linux should follow, with macOS being the least priority.
• Bundles should be put together with containerization in mind to allow their execution in a modern CI/CD tool like Tekton or Jenkins with container agents.

Advanced users with access to container runtimes should be able to continue using Kantra as they do today, allowing them to use multiple providers with a single installation.

[konveyor-ci-bot]

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members.

[rromannissen]

@brunoborges let me know if you find anything missing. @dymurray @pranavgaikwad @shawn-hurley @eemcmullan please review.

[shawn-hurley]

If we can expand on what restrictions we mean by "Admin permissions and privileged execution requirements must be avoided as well as users are unlikely to have access to them."

Does this mean they can not open any non-reserved ports?

[rromannissen]

I guess that would depend an should be dealt with on a per case basis. In the Windows domain, things that come to mind could be requiring use the "run as administrator" permission escalation or requiring PowerShell, since it's not an uncommon practice to disable it in corporate security policies.

[shawn-hurley]

If we could get a list of common actions that cause someone to need this that would be helpful. The main concern I have is assuming that we can run the providers over the local network of the machine, but if that requires admin, then we basically have to build an entire new communcation flow.