feat(web): Expose experimental account storage API

[jvz]

This adds some of the REST APIs introduced in the experimental account
storage API in Clouddriver to Gate. Initially, these APIs are only
available for admins.

spinnaker/spinnaker#6525

Requires spinnaker/clouddriver#5594

[spinnakerbot]

We prefer that non-test backend code be written in Java or Kotlin, rather than Groovy. The following files have been added and written in Groovy:

• gate-web/src/main/groovy/com/netflix/spinnaker/gate/controllers/AccountController.groovy

See our server-side commit conventions here.

[jvz]

Note: I've changed permissions here to allow any authenticated user to create an account definition. It's on them to specify relevant permissions. Requires WRITE permissions to update and otherwise use the account (same semantics as READ and WRITE permissions on accounts everywhere else).

[dbyron-sf]

I forget how this was previously, but I suspect we'd like to lock this down more than this. At least WRITE permissions makes sense to me. I suppose other permissions likely need to be in place for spinnaker to be able to use an account, so I can see how opening it up could be ok...but if nothing else it feels like opening up to mistakes, or possibly even a denial of service as extra accounts use resources.

[jvz]

Previously, I had an admin check on these endpoints. Given that users have to supply their own credentials references (and grant the running Spinnaker access to those secrets), there doesn't seem to be much to secure here. I was thinking perhaps a config setting or table for storing groups or roles that are allowed to create/update/delete resources here, though users will only be able to affect accounts they have permission to write, and they have the ability to grant permissions during create to whoever.

[dbyron-sf]

Guess I need to learn more what's in a credentials reference...but isn't there still a possibility of some malicious user creating a ton of accounts -- even ones that spinnaker doesn't have access to -- and using a bunch of resources. I'm thinking of attempting to cache those accounts and then spamming the logs.

[jvz]

That's a fair concern, though there's already a security setting for which group(s) are required in order to login. I haven't been able to think of a better way to manage the permissions to create accounts, though perhaps that could be a config setting rather than anything dynamic?

[jvz]

For my own usage, I want users to be able to configure their own account credentials without involving the developers to update our config and redeploy anything. I also want to stop using shared account credentials, but that's difficult to do without providing a way for users to configure their own credentials (i.e., I don't have access to the same systems as my users do, so the user is responsible for linking their system to ours either way whether it be via importing a secret or by granting access to my shared credentials to their system). This is also why I'm thinking it might make sense to make configurable as some use cases could be like mine while other people's use cases could be more locked down.

[xibz]

@dbyron-sf - I work with @jvz, and as jvz stated, we want people to be able to fully manage there accounts. That can be through creation or setting limitations.

One thing jvz and I have talked about is potentially allowing you to add a pluggable authorizer to allow users to specify the limitations that they wants. How does that sound?

[dbyron-sf]

That could be ok...but sounds fancier/more complicated than maybe we need? Would a config flag be enough? I'm assuming fiat, so then it's configuring required permissions there...

[xibz]

Yea, config flag would suffice as well. Generally permissions can get complicated, so having a pluggable authorizer may be nice. However, we can start with a config flag and if things get complicated, we can always change it :)

[dbyron-sf]

After some offline conversations, sounds like we're going to stick with isAuthorized for this PR and move to something that uses fiat as a second step. Is there some way to mark these endpoints as Alpha until they stabilize?

[jvz]

This was also updated to allow users with WRITE permissions on the account to update it.