Customers should be prevented from causing harm when we are hosting Octopus Server on their behalf

[michaelnoonan]

See this working document: https://docs.google.com/document/d/1-2RTk8oZDbDK78pv20_RPP422CKYnaMVPoYXHnoWNT4/edit

We want to prevent customers from breaking their own Octopus Servers when we host it for them. They shouldn't be able to:

1. See sensitive information about how the server is hosted which may weaken the security of their Octopus Server
2. Change settings which may lead to downtime or otherwise negatively impact the service we can provide.

Similarly, our customers may be concerned if they discover we have too much access (by default) to their Octopus data. *Granted, we still have root access to everything, but it would be nice if our customers knew when we logged in to their Octopus Server, we can't see their data by default. They could invite us to do so as an explicit grant._

Note: this would also be of benefit to our enterprise customers who want hosting configuration to be untouchable by their development teams.

Suggested Solution

After looking at these areas, it appears using the existing Permissions system would be suitable. The majority of these areas already assert the AdministerSystem permission, however that permission is asserted by a variety of activities. We could introduce another permission to differentiate between:

1. Things the can be seen/changed by the hosting provider.
2. Things that can be seen/changed by the Customer.

API and UI

These preventions should be enforced at the domain/API layer, and re-inforced in the UI. A customer might get tricky and try using the API do to things.

Managing Teams

We will have to think about how to prevent someone with TeamEdit or RoleEdit from elevating their privileges and granting themselves access to hosting configuration.

Identified problem areas

Here is a starting point of the areas we've identified which need some attention.

Area: Configuration

Customers can access the green bits - it's useful to them. Only the hosting admins should access the red bits.

Area: Configuration > Settings

We can just leave Active Directory and Guest extension packages out of the bundled files.

Area: Configuration > Settings >

Area: Configuration > Nodes > Server Settings

Delete!

Area: Configuration > License > Upgrade Notifications

When hosted orchestrator deploys an instance of Octopus Server, it will set this configuration to NEVER. We should prevent the customers from changing it to anything else.

[michaelnoonan]

Customers should be prevented from causing harm when we are hosting Octopus Server on their behalf

[distantcam]

If you remove the AdministerSystem permission, but keep all the others the majority of the configuration sections disappear. From the list we want above, Features, Settings, Thumbprint, and User Invites are the ones still missing.

Adding new permissions

ConfigurationView and ConfigurationEdit permissions apply to the following endpoints.

• GET /api/configuration
• GET /api/configuration/{id}
• GET /api/configuration/{id}/metadata
• GET /api/configuration/{id}/values
• PUT /api/configuration/{id}/values

FeatureView and FeatureEdit apply to the following endpoint.

• GET /api/featuresconfiguration
• PUT /api/featuresconfiguration

Existing permissions

Thumbprint requires the MachineEdit permission in the API, so I added that to the UI. User Invites requires the UserInvite permission in the API, so I added that to the UI.

New Role and Team

I added the new built in role Owner and gave it all permissions except AdministerSystem. Then I created a new built in team called Octopus Owners with the new Owners role.

This provides most of the changes needed to configure the server into a hosted state.

I've made these changes on the hosted-perms-wip branch.

[matt-richardson]

@michaelnoonan - I think you've marked SMTP incorrectly. End users should be able to edit SMTP settings - they are just pointing to their own SMTP server.

[michaelnoonan]

@distantcam yes, @matt-richardson is right! SMTP should be user-configurable. We want them to set up their own SMTP servers and use those. We don't want to be in the business of being spambots. :)

[michaelnoonan]

Release Note: Introduced new highly privileged team and role to take the place of Octopus Administrators in Octopus Cloud

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.