Generator-jhipster: [FEATURE] Allow access to secured management endpoints using basic auth

[PierreBesson]

Overview of the feature request

Allow requests be made to /management/XXX using a fixed API key that would be defined in the properties (for example jhipster.security.authentication.management-api-key).
This api key could be passed in the header and let users access the management API without a regular user authentication. This would also lead to the creation of a new Spring "Authority" which would be call ROLE_MANAGEMENT.

Motivation for or Use Case

@clement26695 is almost done with the Micrometer migration and we have decided to support prometheus by default. So in addition to the metrics screen, the app will expose prometheus metrics on /management/prometheus. However this poses a problem as this endpoint is not secured.

So I have looked at the Prometheus security docs on how they recommend to do this and the answers have been very lacking. It appalling that the Prometheus devs don't care too much about security and even point to a security audit which includes this section.

---

---

After reading the docs further, I found that it is possible to configure the Prometheus server to provide an API key to be passed in the Authorization header when querying the app prometheus endpoints.

Implementing this fixed API key feature will also help for many other use cases for example to access actuator endpoints from scripts, to provide management rights for non admin users (now that we will have a management authority which can be attributed users other than admins). It can also be helpful for the registry to restrict its access as it currently has admin rights to all apps.

Proposed implementation

Add a new Spring Security filter and securityConfigurerAdapter to achieve fixed API key security for /management endpoints. The feature would only be enabled when the new management-api-key property is defined.

Related issues or PR

None that I know of

• [X] Checking this box is mandatory (this is just to show you read everything)

[PierreBesson]

For now, @clement26695 has enabled public access for the prometheus endpoint: https://github.com/jhipster/generator-jhipster/commit/6e50fc845b62f5396f9c8cdf52b53af185079d60.

[atomfrede]

When I enabled Prometheus again for our current setup I enabled basic auth
for that endpoint and configured Prometheus to query that endpoint with
basic auth. But an API key might be easier.

On Wed, Dec 12, 2018, 18:56 Pierre Besson <[email protected] wrote:

For now, @clement26695 https://github.com/clement26695 has enabled
public access for the prometheus endpoint: 6e50fc8
https://github.com/jhipster/generator-jhipster/commit/6e50fc845b62f5396f9c8cdf52b53af185079d60
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/8946#issuecomment-446681732,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMaib9B9Sq6G2HdpWTxxZdzOFU9MJKgks5u4UM0gaJpZM4ZQDeP
.

[PierreBesson]

Well basic auth could make sense as a simple solution. So basically we could create a special "management" user with ROLE_MANAGEMENT and password set in the properties. I'm not sure which solution is better.

[atomfrede]

Also not sure. The basic auth solution will work pretty straight forward (https://www.jhipster.tech/monitoring/#configuring-metrics-forwarding. Not sure how much "more" work it is to protect one endpoint with a special token.

[cbornet]

I'm also in favor of the Basic Auth solution as it's built-in spring security and can be used from different users.

[PierreBesson]

Basic auth is an other solution which has the advantage of being more standard but to you need both the user/pass and not just a key. However I don't like to use the admin user for this so it should be a special user with a special role.

However the way I coded this, it can be a special feature or the JHipster framework (just one property to set) and it can be useful to secure management endpoints when accessing them from the registry for example...

[cbornet]

We could just create the new role and a new user with Basic Auth. The advantage would be that you could attribute the role to whatever user you want.
I'm not sure of what is the advantage of a key over a user/pass...

[PierreBesson]

It seems like this needs a vote. @jhipster/developers, do you have a preference between the basic auth and api key solution. Please vote:

• 🎉: basic auth
• ❤️ : API key

[gmarziou]

In both cases, how would you configure and manage them? Only in app properties?

[PierreBesson]

Yes it is only in app properties.
Anyway, I need to point out that we really need this because of Prometheus and its pull model. Personally I'm not a big fan of the pull model because I don't want to expose my metrics publicly. It forces you to set up proxy in front just to prevent access to the prometheus endpoint which the prometheus authors don't see as a problem.
However Prometheus is the most popular metrics solution which has modern features (histogram aggregation, tagging) so we have to put up with it.

[cbornet]

For me it shouldn't be an app property. It should be a user attribute (whether it's the password or a key). Especially if we use Spring security's role management.
If you want to use a global API management key (not linked to a user) then we shouldn't use Spring security for this and just have a filter that rejects the request if the API key is wrong.
As for the current PR : what if the someone creates a real user named "manager" ?

[PierreBesson]

I guess the Basic Auth solution is more popular so I will go with it. In the end it's will be less code to maintain.

[jdubois]

@PierreBesson as you closed the PR, shouldn't we also close this ticket?

[PierreBesson]

No I still want to do it.

[PierreBesson]

OK, so I lost tons of time on this (3 months!) and in the end could not find a satisfactory solution to have it work with all auth schemes, the front-end management pages (the same endpoint should also be accessible with JWT token, session, etc.) and not being too complex to configure for the user. So I'm doing a PR to leave the prometheus endpoint open for now. And we will advise our users that they either want to prevent access to /prometheus with a proxy or change the management.port.

[jdubois]

Fully agree with you @PierreBesson !! So sorry you lost time here, let's move to more exciting stuff!

[cbornet]

Accessing the Prometheus endpoint should now be possible with Basic Auth for JWT auth option (see https://github.com/jhipster/generator-jhipster/pull/9585)
For the others (session, oauth, uaa), we could have the following endpoint that checks for an API key:

@RestController
public class PrometheusResource {

    private final PrometheusScrapeEndpoint endpoint;
    private final String apiKey;

    public PrometheusResource(PrometheusScrapeEndpoint endpoint, @Value("${jhipster.security.prometheus-key}") String apiKey) {
        this.endpoint = endpoint;
        this.apiKey = apiKey;
    }

    @GetMapping("/management/prom")
    public String prom(@RequestHeader("Key") String apiKey) {
        if(!apiKey.equals(this.apiKey)) {
            throw new AccessDeniedException("Wrong Prometheus API key");
        }
        return endpoint.scrape();
    }
}

This way we can protect the actuator endpoint with Spring security and leave this one unsecured. WDYT ?

[PierreBesson]

@cbornet This is actually a brilliant idea. I think we should make this endpoint a Spring Boot "Endpoint" so that it will be compatible with both webmvc and webflux. This can also be setup purely on the lib and we could override the official endpoint to add optional security with a key.