Make reading secrets explicit in permission verbs.

[fspmarshall]

Read permissions are currently scoped to one of two verbs, VerbRead and VerbReadNoSecrets. This is potentially confusing, and has lead to issues where resources which did not contain secrets were scoped to VerbRead, making it difficult to add secrets to the resource later without complex migration. It also increases the likelihood of unintentionally granting access to secrets since this naming scheme makes access to secretes "opt out" as opposed to "opt in".

Proposed Solution:

Introduce VerbReadWithSecrets to replace the current behavior of VerbRead, and deprecate VerbReadNoSecrets since "no secrets" should always be the default behavior.

[klizhentas]

@benarent we should make sure that it's not a customer impacting change - to my knowledge read no secrets was never exposed, so safe to replace, but we should check this.

[benarent]

Apologies for not reviewing this sooner. @fspmarshall Do you have any scenarios in which you can see customers already interacting with this? I take this was from your work with backup and restore?

[fspmarshall]

I take this was from your work with backup and restore?

Yeah, this came up originally when dealing with adding the ability to export user authentication data.

Do you have any scenarios in which you can see customers already interacting with this?

I doubt removing VerbReadNoSecrets will be an issue, it has been left undocumented (probably deliberately). Changing the default behavior of VerbRead to not imply access to secrets might affect existing users tho. We'd need to figure out exactly which APIs needed to be rescoped under VerbReadWithSecrets before we could be certain. Deciding the the correct scoping isn't trivial since VerbReadNoSecrets hasn't been used consistently, and I haven't had the time to give it the serious attention it requires.

At a guess, this change is most likely to affect people using remote tctl execution (#2991).