Tenant Security with Packages and Lifecycles

As our solution makes heavy use of Tenants we’ve been uncovering a number of security floors which I have logged.

In addition to those is the ability to restrict who can see Packages and Lifecycles.

For example, TenantA is connected to ProjectA which uses PackageA and LifecycleA. I believe that it is a security floor for someone from TenantB to see PackageA and LifecycleA.

Could you confirm that this data isn’t currently filtered based on what Tenant(s) you belong to?


Thanks for keeping in touch! I think it would be nice if we could hook up on a screen share and go through your scenario in more depth.

Can you book a time that suits you so we can work through this together? https://calendly.com/octopusdeploy/supportcall

In the meantime, packages and lifecycles are both treated as shared resources and don’t participate in “scoped permissions” (restrictions via environment, tenant, project). We are currently working on a project called Spaces, which may be a good fit since each Space is essentially a fully secure sandbox, but it may also be too heavy-handed.

Hope that helps!

Hey Michael sorry for not responding sooner. Have been in away for work for a few weeks.

A support call would be really helpful and greatly appreciated.

I have just setup a Calendy account however the link you sent through doesn’t seem to work anymore. Could you resend?

Hi Mike would you have time next week for the support call?

Thanks heaps!


Something went wrong with our Calendly site. It should be back up and running now.

To speak with me directly, it might be best to use this calendar instead: https://octopus.appointlet.com/s/chat-1-hour/michael-noonan

It links directly to my calendar and my avaialbility.

Hope that helps!

Hi Patrick,

Thanks for spending the time with me yesterday. Here are some notes from our conversation:

Prompted Variables for Offline Drops
I think this is the closest suggestion we have so far for this kind of feature. I’d suggest lending your support and providing some specifics about your use-case and how you’d see it working. https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/12794610-allow-for-display-and-edit-of-offline-variables-at

Variable Unification
I’ve emailed an invitation to comment on that working document.

Suggestion: Library Variable Set per Tenant
As I mentioned, I think you’ll have a better experience while you are still using Library Variable Sets, to use each set as a sandbox. There are some downsides (needing multiple sets, and scoping each variable manually) but you should get the isolation you’re hoping for.

Suggestion: Make each developer/tester a Tenant
A core tenet of Octopus is to make your deployments as consistent as possible across your environments. In this case I’d recommend modelling any of your “sandboxes” in the same was as you do for Production. When each developer/tester becomes a tenant, you’ll be exercising the self-same deployment strategy across all your environments. Plus you’ll have the dashboard telling you the truth about your sandboxes, and make it harder to pave over someone else’s sandbox. Plus you won’t have to use the “Include Specific Machines” workaround you showed me.

Database backup
Can you take a backup of your SQL Server database for Octopus, zip it and upload it to the location in the email I’ve sent?

Hope that helps!

Thanks Michael. I greatly appreciate the meeting yesterday. It really helped a lot.

I’ve just uploaded our Database to the link provided.

Am looking forward to your feedback regarding what the issue could be.