Improve server-acl-init: Avoid forcibly creating the anonymous token policy when it already exists

[inisitijitty]

Is your feature request related to a problem? Please describe.

I am using Consul with admin partitions, each with its own Helm deployment. In my setup, I've observed that the server-acl-init subcommand forcefully wants to create the anonymous token policy in the default admin partition, even if it already exists. This behavior requires me to grant the bootstrap token acl = "write" permissions, which is not ideal for the security model I am aiming for.

Feature Description

I propose a change where the server-acl-init subcommand first checks if the anonymous token policy already exists before creating it. If the policy is already present, then no action is taken. This would reduce the scope of the bootstrap token permissions, enhancing the overall security and reducing the possibility of privilege escalation.

Here are the relevant code sections:

• Current server-acl-init behavior: Link
• Desired behavior from partition-init: Link

Use Case(s)

This feature is particularly useful in scenarios where you are running Consul on Kubernetes in a multi-tenant environment with admin partitions. Each partition requires its own Helm deployment and managing ACL policies becomes crucial to maintaining secure boundaries between different partitions.

Contributions

I would be happy to contribute to this feature, but I may need some guidance on how to get started as this is my first time contributing to Consul.

[david-yu]

Thanks for filing, this has also been raised internally as a feature request for triaging and prioritization since this is coming from a Consul Enterprise customer.

[aahel]

Is your feature request related to a problem? Please describe.

I am using Consul with admin partitions, each with its own Helm deployment. In my setup, I've observed that the server-acl-init subcommand forcefully wants to create the anonymous token policy in the default admin partition, even if it already exists. This behavior requires me to grant the bootstrap token acl = "write" permissions, which is not ideal for the security model I am aiming for.

Feature Description

I propose a change where the server-acl-init subcommand first checks if the anonymous token policy already exists before creating it. If the policy is already present, then no action is taken. This would reduce the scope of the bootstrap token permissions, enhancing the overall security and reducing the possibility of privilege escalation.

Here are the relevant code sections:

• Current server-acl-init behavior: Link
• Desired behavior from partition-init: Link

Use Case(s)

This feature is particularly useful in scenarios where you are running Consul on Kubernetes in a multi-tenant environment with admin partitions. Each partition requires its own Helm deployment and managing ACL policies becomes crucial to maintaining secure boundaries between different partitions.

Contributions

I would be happy to contribute to this feature, but I may need some guidance on how to get started as this is my first time contributing to Consul.

@inisitijitty do you want to use the acl:read for the partition token ? the partition token requires acl:write privilage to create other policies like the cross-namespace-policy.

[inisitijitty]

@inisitijitty do you want to use the acl:read for the partition token ? the partition token requires acl:write privilage to create other policies like the cross-namespace-policy.

The cross-namespace-policy is established within the admin partition targeted by my deployment. Therefore, I can grant the acl:write permission directly to the partition.

partition "my-partition" {
  acl = "write"
  ...skipped...
}

To offer a bit more background, I'm giving my users a bootstrap token and I intend to associate it with the following policies:

acl = "read"
operator = "read"
agent_prefix "" {
  policy = "read"
}

partition "my-partition" {
  acl = "write"
  mesh = "write"
  peering = "write"
  namespace_prefix "" {
    policy = "write"
  }
  service_prefix "" {
    policy = "write"
  }
}

This setup doesn't work as intended. As highlighted earlier, the server-acl-init subcommand forcefully wants to create the anonymous token policy within the default admin partition. This happens regardless of whether the policy already exists, compelling me to modify the initial policy to:

acl = "write"
operator = "read"
agent_prefix "" {
  policy = "read"
}

And this doesn't fit the security model I have in mind.