Ignore objects with names that end with / when listing rule groups

[pstibrany]

What this PR does: This PR changes bucket-client based rule-store implementation to ignore objects that end with /. Such objects may exist and would be returned, but would cause failure to load the rule later, which can lead to ruler not loading any rules.

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[pracucci]

Thanks for the fix! LGMT

[pracucci]

I approved, but I'm doing a step back now. / is a valid base64 character, so we may have it within the key name as well, which would break the logic anyway. Also having the key with / at the end may be legit 🤔

Am I missing anything?

I need more thinking on it

[pstibrany]

I approved, but I'm doing a step back now. / is a valid base64 character, so we may have it within the key name as well, which would break the logic anyway. Also having the key with / at the end may be legit 🤔

Am I missing anything?

We use base64 with "URL" alphabet (ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_), so / is not a valid character.

Key with / is legal in general, but our rule group objects must have non-empty name, which implies that they cannot have name ending with /.

[pracucci]

We use base64 with "URL" alphabet (ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_), so / is not a valid character.

Interesting. So, how can we end up with an object ending with /?

[pstibrany]

Interesting. So, how can we end up with an object ending with /?

Objects that we've found are from Aug 2020 and Dec 2020. I suspect that we didn't check for group or namespace names in the past (do we now?). Content of those files is suspicious too -- they don't look like rule group files at all.

[pracucci]

Objects that we've found are from Aug 2020 and Dec 2020. I suspect that we didn't check for group or namespace names in the past (do we now?). Content of those files is suspicious too -- they don't look like rule group files at all.

My though is: if such objects are not supposed to be there, should we filter them out (this PR)? I would bet we can break several parts of cortex if the storage contains unexpected objects.

[pstibrany]

Note that validation for empty group names was added in #3210.

[pracucci]

Looks very good to me, thanks!