The Premise
The CI server (i.e. TeamCity, TFS, etc) build in the CI/CD pipeline typically does a lot of the same things from project to project. Such a build generally might run requisite code compilation, automated testing and DB migration testing; followed up with the publishing of deployment packages and creation/deployment of a release to a test environment following the success of all the previous steps. Service users that execute these processes are often given extremely broad permissions that encompass far more than needed and can expose your infrastructure to harmful actions whether intentional or unintentional.
In this example we’ll establish a setup for the minimal permissions necessary in that final step of the process: automatically pushing packages and releasing via Octopus Deploy. A couple important reasons for minimal access given to the CI process are:
The compromised credentials involved (here, a generated API key) can have minimal scope and impact when in nefarious hands, and
Minimal negative actions can be performed via the build process either intentionally or (more likely) unintentionally by developers through the changing of the build script, variable setting goofs, and things of that nature.
So let’s create a maintainable security setup in Octopus Deploy to facilitate these types of processes. In the following steps we will cover creation of the service user and dedicated API key, and the creation of a reusable Role and a new Team.
Dedicated CI Service User
Create a new user under Configuration->Users. This user will be assigned permissions to perform all of the CI tasks. Clicking “The user is a service user†will remove the need for entering a password and allow you to create it.
Once created click the “New API Key†button. This secret key alone will serve as authentication of this service user when the CI process does any interactions with the Octopus server. Make sure to plug it into your CI process now or set it aside, because you will not be able to read its value again after you leave this page.
Roles and Teams
After being created, the service user has no permissions beyond what’s given to the Everyone team. For finely detailed control of permissions, we’ll create a team just for this kind of user, and a role for that team with only the exact permissions need. The role should be created first, and you can get there by first going to the Configuration->Teams page, and clicking the link at the top right.
Add a custom a role and give it these permissions based on what your CI process will be doing…
If the CI process will be publishing deployment packages to the Octopus server’s internal nuget feed via a built-in CI server build step or a command like:
NuGet.exe push YourApp.nupkg -ApiKey -Source https:// localhost:8888/nuget/packages
Use this permission:
- BuiltInFeedPush
If the CI process then needs to create a release from published packages, by a built-in CI server build step or a command like:
octo.exe create-release –project=
–version= –packageVersion= –server= –apiKey= –enableServiceMessages
Use these permissions:
- ProjectView
- ProcessView
- ReleaseView
- ReleaseCreate
Lastly, if the CI process needs to also deploy the release, for example by adding these options to the end of the previous command:
–deployto= –waitfordeployment
Add these permissions too:
- DeploymentCreate
- DeploymentView
- TaskView
CI Integration Team
The final step for security setup is to create the team for the CI service user. You can create this from the Configuration->Teams page.
Here you’ll give it a name like “CI Integration†and assign both the CI service user to Members, and the CI Integrator Role to the Roles. It’s good to also put in a restriction here for what environments this team is allowed to operate on, like this example which specifies the initial “Test†environment. This asserts that no matter what might get messed up with what this integrator is doing, the only place it will effect is the environment farthest away from production.
Another consideration here is the option to restrict this team to a specific project group or, more specifically an individual project or projects. This decision often comes down to the nature of your deployments across projects, and what exposure letting a single CI user or API key have access to all projects might risk to your organization. In a situation where, for example, everything is nothing more than just a simple deployment of a web application, this exposure might be a perfectly acceptable risk given the “Environments†restriction, but in other will far more complex or sensitive activity, you may opt to create these teams and CI users on a project by project basis.
This article is based on Octopus deploy v3.8.2.
The title of this article is based on a very emotional scene from what is widely considered among critics as the worst Star Trek movie in the entire series, Star Trek V: The Final Frontier.
