Add Java API client example

[JfcAtCyberArk]

Is your feature request related to a problem? Please describe.

I would like to see https://github.com/cyberark/conjur-api-java integrated in this project because it would help to demonstrate how it works but could also benefit https://github.com/conjurdemos/kubernetes-conjur-demo where there are no API client example.

Describe the solution you would like

I would like to be able to demo secretless, summon and API client integrations with the same applications (and so same docker image). To do so, I was thinking about the addition of a "SecretController".

Describe alternatives you have considered

I considered using my own app but I do think one demo app could be leveraged for several integrations and I think the number of Git projects should remain as low as possible, not to be confusing.

Additional context

I've done it in a private project but would like to know your thoughts.

[BradleyBoutcher]

Hi @JfcAtCyberArk, there is a demo I worked on here, https://github.com/conjurdemos/dap-intro/tree/master/demos/java-api-client that may be useful for this issue

It looks like we have a setup script to run it in openshift currently: https://github.com/conjurdemos/dap-intro/tree/master/demos/openshift-install

However, I believe we're moving away from using this repo. We could migrate this demo over here perhaps, or something along those lines. @mdodell also wrote a demo that uses this api in a Kubernetes space, I believe.

[sgnn7]

Hey @JfcAtCyberArk ,
There's also https://github.com/conjurdemos/dap-intro/tree/master/demos/java-api-client where there's an example of how to use that API too :)

[JfcAtCyberArk]

Hey @BradleyBoutcher @sgnn7 !

Thanks for your answers. I realized I made a mistake:
"could also benefit https://github.com/cyberark/conjur-api-java" -->
"could also benefit https://github.com/conjurdemos/kubernetes-conjur-demo"
I edited my first comment.

In kubernetes-conjur-demo there are 3 apps: secretless, summon-sidecar and summon-init.
I would like to switch summon-sidecar to api_client-sidecar as summon with a sidecar does not have much sense.
And doing so with the same demo app will allow better demos, ease understanding and keep the number of docker images low.

I was thinking about something like the below:

package hello.controller;

import java.net.URI;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.http.ResponseEntity;
import com.cyberark.conjur.api.Conjur;


@RestController
class SecretController {
  @GetMapping("/secret")
  ResponseEntity<?> getSecret() {
      Conjur conjur = new Conjur();
      String secret = conjur.variables().retrieveSecret(System.getenv("SECRET_PATH"));
      return ResponseEntity.ok().body(secret);
  }
}

Thank you for sharing examples but I was more looking for a way to illustrate all our secrets delivery option with the same app.
As the pet-store-demo app is used in https://github.com/conjurdemos/kubernetes-conjur-demo, it would require an update.

I would be happy to file a PR but would like to know what do you think about adding additional Java dependencies that might not be used if the app is integrated with Summon or Secretless.

Thanks!

JFC

[izgeri]

The purpose of this app is to enable demos where the secret values the app requires to communicate to the DB have been injected into the environment.

It sounds like you want to use this app differently; where it will invoke the Java client to retrieve the secrets itself. I'm not opposed to having a default-off configuration flag added to this app that will have it retrieve the secrets itself (and inject them into env vars, maybe, for simplicity?) - I would prefer to keep the default flow so that the app looks for the secret vals in the env, however.

Does that make sense? Can you think of a way to update this so that if, for example, USE_CONJUR_CLIENT is set to true in the app env, then the app invokes the Java client rather than passively expecting the secret vals to already be set in the env?

If I've misunderstood your proposed change, please let me know. Thanks!

[JfcAtCyberArk]

Hi @izgeri,

I am looking to answer this: "Where can I find a publicly available Docker image of a Java application that uses conjur-api-java?"
I think pet-store-demo could be a good fit as this is the demo-app used with summon and secretless.

My proposed change is just about adding a controller that would fetch a secret from Conjur (same idea as vulnerable controller)
It might be a very simple and not realistic example but it's enough for demo purposes.
WDYT?

We could keep the summon-sidecar pod. It would just be able to leverage the access token one more time to perform an API call to fetch SECRET_PATH

The datasource configuration could be done programatically and it could coexist with application.yml according to the overriding rules but it would require more changes and an update of the pom.xml aswell.
Something like:

import javax.sql.DataSource;
import org.springframework.boot.jdbc.DataSourceBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class DataSourceConfig {
    
    @Bean
    public DataSource getDataSource() {
        DataSourceBuilder dataSourceBuilder = DataSourceBuilder.create();
        dataSourceBuilder.driverClassName("org.h2.Driver");
        dataSourceBuilder.url("jdbc:h2:mem:test");
        dataSourceBuilder.username("SA");
        dataSourceBuilder.password("");
        return dataSourceBuilder.build();
    }
}

I do not have tested this second option though.

Thanks,
JFC