Hedgehog Documentation

Creating and Customizing Tasks

  • Last Modified: 2019-07-17

The built-in tasks are a good starting point, but as you expand Hedgehog within your organization, you may want to customize tasks to help model governance and compliance policies.

A task has a name and description, and is comprised of a set of more granular security attributes that define what principals may or may not do when granted the task. Some attributes may be scoped to an Environment, whereas others can only be applied to the system scope. For example, orchestration jobs are managed at the system level (and can target any environment), so the "Manage Jobs" attribute cannot be scoped to a single environment.

Proxy Security Attributes

Any system that allows for granular security attributes has the concept of "granting by proxy", or proxy attributes. For example, even if you only grant permission to create and delete files on a file system, you are still granting edit permission by proxy; a user can simply delete and then create a file as a workaround for not being able to edit it. Likewise, users with only edit permissions can delete by proxy, because they can simply edit the file to have no content.

There is no sensible way for any software to prevent proxy operations, which is why it's important to understand what proxy attributes you may be unintentionally allowing.

Nonsensical Security Attributes

Granular security attributes can also lead towards creating "nonsensical" policies. For example, giving manage but not view permissions is nonsensical because you can't manage something you can't view. In this case, the behavior is undefined; generally, you'll be able to view the thing, but there are some places where it might not be visible.

While you wouldn't intentionally create such a policy, it might occur if you create multiple overlapping restrictions and permissions across multiple overlapping groups. The best way to mitigate this risk is to carefully plan your use of restrictions.

Transitive Access

Even with well-planned security restrictions in one part of a system, users can bypass those restrictions from another part of the system that didn't consider the same security restrictions. For example, simply denying view privileges on sensitive files on a network drive is not enough to protect sensitive data; anyone with access to the backups will have transitive access to all those files. Of course, you can encrypt the backups, but then anyone with the decryption key will have transitive access to all the backups.

With Hedgehog, it's especially important to consider transitive access. If Hedgehog can access a production server, and you give users administrative access to Hedgehog, then they can also deploy to that server. There's just no way around that.

Security Attribute Reference

Some of the attributes are denoted with a superscript E or P. E indicates that they are scopable by environment and P indicates that they are scopable by Project.

all permissions

Admin (Configure Hedgehog)

This attribute is a proxy for all other attributes, and should be only granted to people you intend to be system administrators.

It is a sort of "administrative catch all" that is used to secure pages in the administration section not covered by other attributes, including security, extensions, and all settings.

Projects (ViewP & ManageP)

View allows users to view everything within a project with the exception of deployment logs and deployment plans.

Manage allows users to do the following:

  • change the project's name, description, raft, and parent project
  • edit configuration variables scoped to the project
  • soft delete (i.e. not purge)
  • create sub-projects
  • manage security grants scoped to the project

Note that manage is a proxy attribute for all project-related attributes (pipelines, etc).

Infrastructure (Manage)

This allows users to create, edit, and delete servers, roles, and environments.

This can provide transitive access to all connected servers and should be granted with extreme care.

Pipelines (ManageP)

This allows users to create, edit, and delete pipelines. This provides transitive access to deploy to force packages to environments, as a user can simply edit a pipeline to remove any gates or deployment windows.

Plans (View ContentsP & ManageP)

View allows users to open deployment plans and view the contents.

You shouldn't put sensitive information (like passwords) in your plans, so there's no good reason to restrict this.

Manage will allow users to create, edit, and delete deployment plans. Note that this provides transitive access to all servers that a user can deploy to.

Deployment sets (CreateP, DeployPE, ForcePE, ManageP, View Deployment Logs/DebugPE)

Create allows users to only create new deployment sets, optionally based on a template.

There are some rare scenarios where you would only want to allow this without other Deployment set-related attributes.

Deploy allows users to promote a deployment set to a stage that it is eligible to deploy to (i.e. passed gates, deployment windows, etc).

Force allows users to bypass these gates.

Manage allows users to add packages, upload local packages, change variables, and change deployment set status.

View Deployment Logs and View Deployment Debug Logs are primarily designed to restrict sensitive data that is consequently logged. The "Debug" logs will hide only the debug-level logs (which is where most tools will log sensitive data).

Releases (ManageP)

This allows users to create releases, change variables, and change release status.

Script Assets (ManageP, View ContentsP)

View allows users to open script assets and view the contents.

You shouldn't put sensitive information (like passwords) in your scripts, so there's no good reason to restrict this.

Manage will allow users to create, edit, and delete script assets.

Because deployment plans can already run arbitrary commands, and editing script assets used by plans can enable any behavior, there's little security value in allowing only one of these tasks. However, you may wish to limit by responsibility, and may find this a convenient way to do it.

Credentials (Manage and View PasswordsE)

View Passwords will allow users to view sensitive (encrypted) fields on resource credentials.

This attribute primarily exists to allow some users to view credentials only associated with certain environments.

Manage will allow users to create, edit, delete credentials, as well as view all sensitive (encrypted) fields.

This could provide transitive access to connected systems, so be very careful when granting this.

Calendars (ManageP)

This allows users to create, edit, and delete system calendars.

Is this documentation incorrect or incomplete? Help us by contributing!

This documentation is licensed under CC-BY-SA-4.0 and stored in GitHub.

Generated from commit ce197caa on master