Unauthenticated Read Access

Apicurio Registry 2.0.1.Final is using the Quarkus auth permission functionality. To provide a readonly access for clients one could easily deactivate authentication on specific resources. As an example read access to the APIs could be achieved by setting

quarkus.http.auth.permission.sr-read.policy=permit
quarkus.http.auth.permission.sr-read-post.policy=permit

As posted by @EricWittmann here https://github.com/Apicurio/apicurio-registry/issues/1718#issuecomment-888504169_ this is currently not supported using the auth layer in 2.1.0

Would be good to have a configuration flag or config possibility to disable the required authentication on all read resources as currently defined in sr-read and sr-read-post.

quarkus.http.auth.policy.sr-read-policy.roles-allowed=${registry.auth.roles.admin},${registry.auth.roles.developer},${registry.auth.roles.readonly}
quarkus.http.auth.permission.sr-read.enabled=true
quarkus.http.auth.permission.sr-read.paths=/apis/registry/v2/ids/*,/apis/registry/v2/groups/*,/apis/registry/v1/artifacts/*,/apis/registry/v1/ids/*,/apis/ccompat/v6/subjects/*,/apis/ccompat/v6/schemas/*,/cncf/v0/schemagroups/*,/apis/ibmcompat/v1/*
quarkus.http.auth.permission.sr-read.policy=sr-read-policy
quarkus.http.auth.permission.sr-read.methods=GET,HEAD

quarkus.http.auth.policy.sr-read-post-policy.roles-allowed=${registry.auth.roles.admin},${registry.auth.roles.developer},${registry.auth.roles.readonly}
quarkus.http.auth.permission.sr-read-post.enabled=true
quarkus.http.auth.permission.sr-read-post.paths=,/apis/ccompat/v6/compatibility/*
quarkus.http.auth.permission.sr-read-post.policy=sr-read-post-policy
quarkus.http.auth.permission.sr-read-post.methods=POST

[EricWittmann]

@carlesarnal I appreciate your preference to keep security actually as secure as possible. 😃 Definitely keep advocating for that! In this case I’m going to give the feature a try and see how it’s received in the community. It will be a feature that is off by default, of course. And the implementation doesn’t complicate the authorization interceptor very much (I think it may actually have clarified it a bit).

As an aside - I don’t think adding BASIC credentials to the URL would work for all tools. That URL format (where the username and password are included in the URL) needs to be actually supported by the client using the URL to make a connection. Many tools do not support it.

BTW - I agree that our recommendation for most (all?) use-cases would be to use credentials that have Read-Only permissions rather than using this feature.

[EricWittmann]

I can see an argument for allowing unauthenticated reads. For example, if all Kafka schemas need to be pre-registered (e.g. by a CI/CD process) and approved by some admin user before they get registered, then you have authenticated users always doing the write operations. Then you may have many Kafka applications needing read-only access to the registry in order to produce/consume messages. This can be accomplished (as @christofluethi mentioned) by having a single read-only user with credentials that get configured for every Kafka app (or of course you could/should have separate creds for each Kafka app).

One other argument in favor is for downstream tools that need to consume registry content but don’t support auth. E.g. any tools that might consume something like an OpenAPI spec from a URL.