Unauthenticated Read Access

[christofluethi]

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 #1718 (comment)_ 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 do you have any bandwidth to take a look at this?

[carlesarnal]

I can take a look but I think this needs proper discussion. With my latest comments on the other issue, I think it should be easy enough to differentiate between write/read access even when using basic auth.

[christofluethi]

yes, the comments in the issue #1718 by @carlesarnal help a lot.

In cases where authentication is not really needed one would probably end up with creating one user and spread these credentials to every client. as this general user does not really add a lot of security i still think that unauthenticated read access would add some benefit. It would also reduce the read-access runtime dependencies in terms of performance and service availability as there would be no need to fetch a token. however, that should obviously not be the solution to availability issues on the KC layer.

[carlesarnal]

if authentication is not really needed why enabling it? In most situations, I assume you would run in a closed network. If authentication is not needed for reading but it's needed for write, I would recommend using a user with a read role. Sorry for being a bit closed mind here but I want to understand a bit better the use case since security is obviously a sensible thing and we're considering opening something.

As a recap, in my opinion, we should have two scenarios, one with auth enabled and using roles for operation segregation and another scenario with auth completely disabled. IMO, adding unauthenticated read access mixes those two scenarios and I would prefer not to mix something like that since this can be a never-ending story with a lot of custom auth/authz controllers on the application side making it more and more complicated to configure the application or to use roles properly etc.

That said, it's not that hard to implement unauthenticated read access so I'm completely open to opinions against my arguments. :)

[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.

[carlesarnal]

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).

I don't see why this is an argument for unauthenticated access since as you said, you can configure read-only users with credentials. Even for CI/CD processes I still think that if auth is enabled, every access should be secure.

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.

This is probably a good use case for this but I still think this can be addressed properly from a security POV by e.g. adding basic creds to the URL.

As I said in my previous comment, this is just my opinion, nothing we should follow as a dogma or anything like that :)

[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.