Deployment setup in a PCI environment

henning_christiansen · 11 April 2014 19:04

Hi,

Has anyone here set up Octopus for deployment to a PCI environment, and if so, could you please share your experiences and setup configuration? It is currently preventing us from reaching deployment bliss, and I’d very much like to fix that.

Any input is much appreciated.

mdavies · 14 April 2014 09:21

Hi mate,

I’m currently in the process of setting up a PCI compliant Octopus deployment on a client site. It’s not complete and the setup process is moving quite slowly, but I’ll still share the configuration so far. The best thing you can do is talk to your security/systems guys and find out exactly what you need to do in order to be compliant - everyone’s PCI environments differ slightly, and it’s a fairly complex situation here.

The PCI environment on this particular client site is heavily firewalled. To get access, you lodge a request ticket which once approved, gives you temporary access to the server you need in that environment. We have the following configuration approved:

Install an Octopus VM within that PCI environment
Install an Octopus VM within the normal non-PCI environment
Install tentacles on each of the PCI production web servers

The PCI Octopus and Web VMs have an open firewall rule between them for deploying packages to IIS

The deployment process looks something like this:

Our CI server pushes builds to the non-PCI Octopus, for deployment out to the dev and staging environments (fairly standard).
When we’re ready for a production release, open a PCI access ticket - this allows us temporary firewall access to run a step in non-PCI Octopus to push a NuGet package out to PCI Octopus.

This is the primary reason for all the complexity here - the security guys insisted that packages should be pushed out to the protected environment first, so that we can ensure they aren’t tampered with and then heavily restrict who can deploy them.

With the firewall access still open, a user with credentials on the PCI Octopus VM can login and run a step there to deploy the (now local) NuGet package out to the PCI web servers.

If you can share any further detail about the situation you’re in, I might be able to give you some more tailored advice

henning_christiansen · 15 April 2014 06:13

Thanks for sharing!

Your setup is similar to one of the options we’re considering, but with a bit of added complexity which may be necessary for the security folks.

From what I understand here, the main issue is that you should not be able to initiate a deploy from outside the PCI environment, but whatever you do on the inside is ok. If this is true, we’ll be able to connect two Octopus servers to the same feed, and create releases on the PCI Octopus for the versions we want to deploy.
We lose the ability to promote to PCI with this setup, but it’s the easiest setup that might have a chance to be approved.

I’ll talk to the security people next week (I hope), and post the setup we decide on.

henning_christiansen · 26 August 2014 12:22

Ok, I know these things usually take longer than expected, but I never expected it to take this long.

We’re currently setting up Octopus for PCI, this is our setup:

We have a “PCI” environment configured on the normal Octopus server, and when deploying to that environment the only thing that happens is that the selected package is pushed to an internal nuget feed.

In the PCI environment we have a separate Octopus server, which can access that feed. And the rest is just standard stuff.

Weird how easy that turned out to be in the end.

mdavies · 26 August 2014 14:16

Awesome, thanks for sharing that - I’m sure that approach could be reused by others faced with this problem.

lars_bjonnes · 5 September 2014 08:39

We also use that procedure for PCI compliance, and it works really great.

michael_obrien · 28 November 2014 08:36

“the only thing that happens is that the selected package is pushed to an internal nuget feed.”

Could someone be able to explain how to do this?

Thanks!

mdavies · 28 November 2014 12:14

Keep two internal NuGet feeds, one in your non-PCI environment and one in the PCI environment. Your non-PCI OD server should have access to both, whereas the PCI OD server should only have access to the PCI NuGet feed.

On deployment to “Production”, have a step on the non-PCI OD server which simply mirrors the package to the production feed, allowing the PCI OD server to access it. Hopefully you find that as long as the users who can perform this action is kept fairly locked down, you’ll be fine.

All you’re trying to do here is be able to prove the package you have verified and chosen to deploy sits on a locked down NuGet feed, and can’t be modified between the time you make your PCI access request and the time you deploy.

henning_christiansen · 28 November 2014 12:26

I tried replying by replying to the email. Didn’t work well, I think it started another thread.

You can use the nuget mirror command, as matt mentions above. In a PowerShell script it would look something like this:

nuget mirror $PackageId $TargetFeed/nuget $TargetFeed -version $PackageVersion -source $SourceFeed -apiKey $ApiKey

Where $TargetFeed is the feed that is accessible from the PCI environment.

You can put this in a step template for easy reuse.

Create a step template in your library if you want to reuse it

michael_obrien · 28 November 2014 12:40

Great, thanks a lot guys!