[APM] Audit non authorized endpoints and Authz migration

[iblancof]

Summary

As part of the Authz migrations, we need to handle endpoints that are not using any authorization.

• /internal/apm/fleet/has_apm_policies
• /internal/apm/fleet/agents
• /internal/apm/fleet/java_agent_versions

They are not using any access tags, so we should audit them:

• If no route authorization is required, then a valid reason must be provided. See the developer documentation for more details.
• If authorization is required, then we should properly secure the endpoint.

Important

Deadline January 31, 2025

[elasticmachine]

Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services)

[crespocarlos]

I couldn't find any reasons for these routes not to have any authorization defined.

/internal/apm/fleet/has_apm_policies: This is also used on the tutorial page, so I’m unsure about the consequences of defining authorization.

/internal/apm/fleet/agents: This route returns the secretToken, so it makes sense to define authorization for it. But I think doing it on this ticket now could have a negative impact, as the tutorial page also relies on this info: #203592

/internal/apm/fleet/java_agent_versions: This will be used by fleet UI and only returns static info stored here https://repo1.maven.org/maven2/co/elastic/apm/elastic-apm-agent/maven-metadata.xml. I think this could opt out from authorization

[iblancof]

I couldn't find any reasons for these routes not to have any authorization defined.

/internal/apm/fleet/has_apm_policies: This is also used on the tutorial page, so I’m unsure about the consequences of defining authorization.

/internal/apm/fleet/agents: This route returns the secretToken, so it makes sense to define authorization for it. But I think doing it on this ticket now could have a negative impact, as the tutorial page also relies on this info: #203592

/internal/apm/fleet/java_agent_versions: This will be used by fleet UI and only returns static info stored here https://repo1.maven.org/maven2/co/elastic/apm/elastic-apm-agent/maven-metadata.xml. I think this could opt out from authorization

Thanks for the input @crespocarlos,

It's okay not to add authentication to the endpoints, but we should document a valid reason in the code, as that's the expected change here:

 router.get({
  path: '/api/path',
  security: {
    authz: {
      enabled: false,
      reason: 'This route is opted out from authorization because ...',
    },
  },
  ...
}, handler);

So we could have sth like this:

• /internal/apm/fleet/has_apm_policies : It's being used in the tutorial page, so it needs to be available for users even if they don't have APM permissions.
• /internal/apm/fleet/agents : It's being used in the tutorial page, so it needs to be available for users even if they don't have APM permissions.
• /internal/apm/fleet/java_agent_versions : It returns static information stored in a public file in https://repo1.maven.org/maven2/co/elastic/apm/elastic-apm-agent/maven-metadata.xml

@crespocarlos does that make sense? If I understood correctly, there are no security issues with the first two endpoints, so if we decide to add access tags for consistency, we can do that later.

[crespocarlos]

@iblancof I agree. The only endpoint that could raise some concern about returning sensitive info is the /internal/apm/fleet/agents. But this ticket #203592 will have to be looked at first.

[iblancof]

@iblancof I agree. The only endpoint that could raise some concern about returning sensitive info is the /internal/apm/fleet/agents. But this ticket #203592 will have to be looked at first.

Great, thank you @crespocarlos!

For the sake of having this ready before the January 31, 2025 deadline, I propose keeping the current state of /internal/apm/fleet/agents without authentication, as there don’t seem to have been any issues with it so far. We can revisit the need to add authentication when we work on #203592.

If you agree with it I'll proceed and add the reasoning to all 3 endpoints.