This will likely be reviewed next quarter (April 1st to June 30th, 2024).

I'm going to pick this up initially to help prioritize. @EBernhardson would it make sense for us to have an initial meeting to get a sense of the risk involved? Anyone else to invite on your side. I'll invite some folks from product security

Certainly we can meet up. This is a pretty narrow extension i think we can get by with only me from our side. Feel free to schedule when you have availability. @pfischer or @dcausse could perhaps be optional attendies.

Thank you very much, I sent a calendar invite.

Thanks @EBernhardson for the productive and interesting meeting yesterday.

We decided that the main aspect of this review would be on design / threat model impacts as the code is too small to require review.

We identified two areas that it is recommended are investigated further to see whether any further improvements can be made:

1. 1. Restricting the IP address to the Kubernetes cluster is quite broad as there are many other services running. It would be worth following up with SRE to see if any further network or logical segmentation is possible to further restrict access from internal services.
2. There is a potential concern over leaking of the Authentication header in logs which may be accessible to staff and volunteers. It would be worth checking that the new form of Authorization header developed for this feature is compatible with (hopefully) existing log redaction patterns.

Another mitigation that might help is automatic key rotation but I think this can be deferred to the above measures as it is quite complicated to implement. Provided the key cannot be stolen from logs, and we are confident a stolen key could not be used, it would be sufficient protection.

Provided the key has at least 128-bits of entropy this will resist bruteforce guess attacks over the API. https://en.wikipedia.org/wiki/Password_strength contains a guide to calculating this.

We could likely still do a quick scan of the repo just to make sure there aren't any vulnerable dependencies, secret leaks or obvious issues from static analysis. The only other concern I might have is that the $wgNetworkSessionProviderUsers config obviously needs to be kept in a private repository or config somewhere (PrivateSettings.php, etc.)

@EBernhardson, according to @JMeybohm there is no way to limit the IP ranges of pod/service/namespace to associated them closely with an application (SUP).

In T357353#9748131, @pfischer wrote:

@EBernhardson, according to @JMeybohm there is no way to limit the IP ranges of pod/service/namespace to associated them closely with an application (SUP).

Ok. I know it's hackier, but could that instead be managed via extension config?

In T357353#9748141, @sbassett wrote:

In T357353#9748131, @pfischer wrote:

@EBernhardson, according to @JMeybohm there is no way to limit the IP ranges of pod/service/namespace to associated them closely with an application (SUP).

Ok. I know it's hackier, but could that instead be managed via extension config?

I had a ponder, but I'm not sure how yet. With both our app and the mw app servers living in k8s there might be something related we can do with network policies, but I'm not certain.

Perhaps something is possible with custom headers. For example there could be a header that is stripped from all incoming requests. We then have envoy populate it with the k8s namespace or similar info. We could then filter on the k8s namespace the request came from? I would have to still look into how viable it is to have the incoming requests filtered, i know envoy can do it, our envoy sre's might be amicable, but i'm not 100% up to speed on the request flow since the mw-on-k8s migration.

In T357353#9782050, @EBernhardson wrote:

In T357353#9748141, @sbassett wrote:

In T357353#9748131, @pfischer wrote:

@EBernhardson, according to @JMeybohm there is no way to limit the IP ranges of pod/service/namespace to associated them closely with an application (SUP).

Ok. I know it's hackier, but could that instead be managed via extension config?

I had a ponder, but I'm not sure how yet. With both our app and the mw app servers living in k8s there might be something related we can do with network policies, but I'm not certain.

To be precise here: If the service backing this as well as all consumers are running in the same k8s cluster we could implement network policies that will only allow access from certain workload in the cluster. But I would advice against relying on that because:

• We still have mediawiki appservers in hardware and there will probably be some snowflakes for which I don't know the implications for this
• We won't be able to use this service cross-dc (as we are with all other active/active services), e.g. depooling in an emergency etc. (which would make this a snowflake)

I think if we aren't sure or there's no easy way to do an IP address restriction, we can skip it as this is low risk.

Was there any other tasks or work still outstanding here?

In T357353#9822299, @acooper wrote:

I think if we aren't sure or there's no easy way to do an IP address restriction, we can skip it as this is low risk.

Was there any other tasks or work still outstanding here?

If authentication/authorisation by just the token is okay with you then the remaining work is on us: We would make the IP range check optional or remove it completely.

In T357353#9846161, @pfischer wrote:

If authentication/authorisation by just the token is okay with you then the remaining work is on us: We would make the IP range check optional or remove it completely.

Bearer token authn/z isn't the most secure method available, but it is fairly standard, and how OAuth 2.0 works. As I stated previously, as long as the $wgNetworkSessionProviderUsers config is kept in a private repo/config file (likely PrivateSettings.php on the deployment hosts) and sets a strong token value, this should be low risk, unless @acooper has anything else to add.