Support kerberos authentication for private git repos

[pdaverh]

Is your enhancement related to a problem? Please describe.

Currently, Eclipse Che does not allow credentials known to the cluster to authenticate private git repo access.

Describe the solution you'd like

Instead of user/password authentication for private git repos, I would like Che to leverage kerberos token already known to the cluster. When a project is added to a Che workspace, the git credentials for the source repository should be based on the kerberos credentials of the user running the workspace.

Describe alternatives you've considered

An alternative is to use SSH keys for private git repos, but that will not work in the environment.

Additional context

[l0rd]

@pdaverh this documentation article describes how to inject git credential store files using secrets. Wouldn't that work?

[vitaliy-guliy]

@pdaverh I successfully created and injected git credentials store file to my Che deployment as @l0rd mentioned in the previous comment.
Then, after creating a workspace, file /home/theia/.git-credentials/credentials was automatically created and I was able to clone my private git repository without entering login and password.

Could you give us a bit more details about your case you are trying to solve?

It looks like it's not a question to Che, but configuration issue.

[pdaverh]

The issue is specific to kerberos tokens, as they are different than traditional git credentials.

[l0rd]

@vitaliy-guliy please have a look at https://www.openshift.com/blog/kerberos-sidecar-container

The article explains how a kerberos token is requested/refreshed using the command line tool kinit and how it can be automated using keytab files.

I believe that including kinit in the terminal container (where git is) and mounting a keytab file as a secret would already allow a current Che user to use Kerberos auth for git.

The article goes also into the details of a sidecar approach to automatically refresh the Kerberos tokens. This sidecar approach can be easily implemented with a kerberos plugin for Che. But that goes beyond the scope of this issue and may be discussed later.

So for now I would only document how we can currently configure a Che workspace to:

• Mount kerberos config and keytab file (using the approach described here)
• Include kinit in the workspace container where git is installed
• Manually generate the kerberos token using kinit

@vitaliy-guliy ping me if you need help to setup a git repo using Kerberos auth.

[ericwill]

@vitaliy-guliy please have a look at https://www.openshift.com/blog/kerberos-sidecar-container

The article explains how a kerberos token is requested/refreshed using the command line tool kinit and how it can be automated using keytab files.

I believe that including kinit in the terminal container (where git is) and mounting a keytab file as a secret would already allow a current Che user to use Kerberos auth for git.

The article goes also into the details of a sidecar approach to automatically refresh the Kerberos tokens. This sidecar approach can be easily implemented with a kerberos plugin for Che. But that goes beyond the scope of this issue and may be discussed later.

So for now I would only document how we can currently configure a Che workspace to:

* Mount kerberos config and keytab file (using the approach described [here](https://www.eclipse.org/che/docs/che-7/end-user-guide/mounting-a-secret-as-a-file-or-an-environment-variable-into-a-workspace-container/))

* Include kinit in the workspace container where git is installed

* Manually generate the kerberos token using kinit

@vitaliy-guliy ping me if you need help to setup a git repo using Kerberos auth.

Thanks for the guidance Mario, we'll revisit this issue next sprint (192).

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.