Call klist in sidecar?

[magick93]

In the deployment config, its a little confusing, because both the sidecar, and the main application, are using the same image, which is edseymour/kinit-sidecar.

I'm assuming a more real world example would use the kinit-sidecar to augment a main application container which doesnt contain any kerberos dependencies (separation of concerns principle).

So, in the deploymentconfig, the application container, called example-app, runs the following command:

- /bin/sh
          - -c 
          - 'while true; do echo "*** checking if authenticated"; klist ; sleep 5; done'

This command requires klist.

So, the example that you have provided has two containers, both from the same image. One makes the above command, and the other runs rekinit.sh.

The objective, I feel, should be that kerberos is wholly separate from the application container, and the aplication container doesnt need any kerberos dependencies.

Is it possible that the main container can call this in the side-car? The objective being that all kerberos dependencies are contained within the kerberos sidecar.

[magick93]

Furthermore, when trying to connect to sql server, I'm getting the following error:

Message=Cannot authenticate using Kerberos. Ensure Kerberos has been initialized on the client with 'kinit' and a Service Principal Name has been registered for the SQL Server to allow Kerberos authentication.

So it would seem the application container still needs to have kerberos dependencies installed.

[edseymour]

The initial design was to meet the requirements of an arch spike which demonstrated that the KRB token was visible to an 'app' container. The bare minimum needed to do this was the KRB client packages, and as such an example 'app' container would essentially be the same as kinit-sidecar container (albeit it wouldn't need the same init.sh script). For expediency I used the same container - PRs welcome 😄

To answer your 2nd point that the KRB client tools are needed in the app container - yes, absolutely. Think of this as similar to added 'drivers' to the app container. The original use-case for this was to allow devs to create a tomcat app that used the MS ODBC driver to connect to an external MS SQL instance (BTW check out SQL Server Red Hat Container). In order to do this, we need to add the MS ODBC driver to the base Tomcat image, so in addition to doing this we'd also add the client tools.

This still fulfils the separation pattern of one container managing authentication, for a wholly separate application container.