Outbound connectivity to databases is allow-all by default

[mikkelhegn]

The rust, go and .net SDKs support outbound connections to Redis and Postgres (not go).

Unlike outbound http connections, these are allow-all by default, e.g. you can call any host from the component using this feature.

We should stick to deny-all and implement the functionality similar to http-outbound, where the configuration need to specify which hosts you're allowed to call.

[itowlson]

We need to define how this is going to work though. The set of allowed HTTP hosts is currently fixed in the spin.toml file. For databases, we want the allowed databases to resolve based on the environment/channel - a production deployment will want access to the production database but a test deployment should have access only to the test database.

This may be moot right now when we don't have a full concept of channels, but I don't want to casually bake this into spin.toml; and then find we need to unpick it. Let's try to make a reasonable plan for what our test-staging-production story might look like, and see if we can design to that today, or if we have to adopt an interim solution.

(There were some good discussions a while back around decoupling policy - set by operators - from application building. Might be time to reassess the roadmap on that.)

[lann]

(There were some good discussions a while back around decoupling policy - set by operators - from application building. Might be time to reassess the roadmap on that.)

Yes, I think this is a better long-term approach ("labels" + runtime config), though we'll still need to support existing non-labels interfaces for the time being.

[rylev]

We need this for:

• redis Require user to add redis host to list of allowed listed hosts #1933
• mysql Add address checks for mysql and postgres #1959
• postgres Add address checks for mysql and postgres #1959

We also need to consider moving to the unified allowed_outbound_hosts for http as well.

[vdice]

@rylev is this considered done with #1959?

[rylev]

Yes it would be!