Gocd: Support for Rules in SecretConfig

[maheshp]

Part of #5830

GoCD System admins can defines rules for a SecretConfig. Rules define where the secrets configuration can be used. e.g.

Only pipeline group teamA_pipelines can access following secret config

<secretConfig id="teamA_secrets" pluginId="vault_based_plugin">
    <description>All secrets for env1</description>
     <configuration>
        <property>
            <key>path</key>
            <value>secret/dev/teamA</value>
        </property>
        <property>
            <key>vault_token</key>
            <value>token for team A</value>
        </property>
    </configuration>
    <rules>
        <allow action="refer" type="pipeline_group">teamA_pipelines</allow>  
    </rules>
</secretConfig>

In the above example, consider a GoCD server shared by multiple teams in an organization. A secret config can be defined to lookup for secrets for teamA from an external Secrets Manager like a vault. The SecretConfig can also be configured to have rules using which Admins can restrict the usage of the secrets config to pipeline_groups specific to the teamA.

Types of rule

GoCD will have two types of rule for now -

1. Allow

   • The rule will allow the access of the current entity based on configured type, action and resource

2. Deny

   • The rule will deny the access of the current entity based on configured type, action and resource

Rule syntax

Allow rule example

<allow type="pipeline_group" action="refer">resource_identifier</allow>

Deny example

<deny type="environment" action="refer">resource_identifier</allow>

| | Description | Example |
| -------- | ----------- | ------- |
| type | The attribute represents the type of GoCD config entity. | wildcard * or pipeline_group, environment, template, agent etc... |
| action | The attribute represents that what type of action is allowed on the current entity. | wildcard * or Action refer on secret config means that it can be referred by the entities with matching type and resource |
| resource | A resource name or pattern with a wildcard(* or ?) in it | pipeline_test, environment_prod or a patter like pipeline_* |

• action and type can have a wildcard(*) but it will not support pattern matching e.g. ref*

Note: type and action can be extended later on need basis to different entity types.

Rule evalution

1. Rules are denied by default
   
   
   
   • If rules are not defined on the entity(e.g. on secret config) cannot be referred anywhere.
   
   

The secret config defined in below example cannot be referred anywhere

<secretConfig id="teamA_secrets" pluginId="vault_based_plugin">
    <description>All secrets for env1</description>
     <configuration>
        ...
    </configuration>
    <rules/>
</secretConfig>

OR

<secretConfig id="teamA_secrets" pluginId="vault_based_plugin">
    <description>All secrets for env1</description>
     <configuration>
        ...
    </configuration>
</secretConfig>

1. Rules will be resolved from top to bottom.

Example 1

<rules>
    <deny action="refer" type="pipeline_group">my_*</deny>
    <allow action="refer" type="pipeline_group">my_group</allow>  
</rules>

In the above example pipeline_group my_group cannot refer the secret_config since the first rule denies access using the pattern my_*

Example 2

<rules>
    <allow action="refer" type="pipeline_group">my_group</allow>  
    <deny action="refer" type="pipeline_group">*</deny>
</rules>

In the above example pipeline_group my_group can refer the secret_config since the first rule allows access.

Validation

• Rules defined in an entity(here secret config) should be validated during config_xml save or update through the API.
• Ignore validation of entity name. This can be validated when an entity refers to the SecretConfig.

Uses cases to support

• Allow all pg except one.
• Allow only one pg.
• Allow a group of pg.
• Deny a group of pg.
• Allow any entity to of a specific type to refer.
• Allow any entity_type with any name refer.

[bdpiprava]

Supported type in secret config rule definition

The type in a rule can be set to pipeline_group or environment, which means that can a pipeline group or an environment is allowed to refer secret configs or not.

Pipeline group

<secretConfig id="release_vault" pluginId="cd.go.secret.vault">
    ... <!-- stripped -->
    <rules>
        <allow action="refer" type="pipeline_group">my_group</allow>  
    </rules>
</secretConfig>

In the above example, release_vault is allowed in only pipeline group my_group. Any pipeline within the group can refer to any credentials from the release_vault.

Environment

<secretConfig id="release_vault" pluginId="cd.go.secret.vault">
    ... <!-- stripped -->
    <rules>
        <allow action="refer" type="environment">production</allow>  
    </rules>
</secretConfig>

In the above example, release_vault is only allowed in theproduction environment. Theproduction environment can use any credentials from the release_vault as an environment variable.

---

Template (Won't support)

<secretConfig id="release_vault" pluginId="cd.go.secret.vault">
    ... <!-- stripped -->
    <rules>
        <allow action="refer" type="template">release_docker_image</allow>  
    </rules>
</secretConfig>

In the above example, release_vault is only allowed in release_docker_image template. Any pipeline derived from the template will also get access to secret param defined in the template regardless in which pipeline group it is defined.

The only benefit users will get, is they can share the same template without worrying about credentials.

@gocd/committers, @arvindsv - This is an open question, should we support rule type template or not?

[arvindsv]

@bdpiparva My opinion: I don't think it's necessary. As you said, there's only one small benefit and my preference would be to start simple and add more knobs and switches as needed.

[bdpiprava]

@arvindsv - Sure, so as of now secret config rules validation will apply to pipeline group and environment. User can define a template(let's say xyz) with secret param there will be no restriction based on rules.

Where ever a template xyz is used to create a pipeline, the secret config rule will be evaluated against the pipeline config in which pipeline is being created.

[arvindsv]

Cool. In such a scenario, there should be a useful message when the pipeline fails to save.

[rajiesh]

Verified on 19.6.0 (9478-5f827efbc8001e16417fe13503f5e240d7ed060d)

[rajiesh]

Applying rules during an entity creation/update or during rules update will be tracked in this issue - https://github.com/gocd/gocd/issues/6416