kubernetes_cluster_role_binding & kubernetes_role_binding adding namespace when subject kind is Group

[antonosmond]

Hi

When applying a clusterrolebinding or rolebinding where the subject kind is Group, there should not be a namespace as a group is not a namespaced resource.
There's documentation here: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-examples

Terraform Version

Terraform v0.12.16

• provider.aws v2.42.0
• provider.kubernetes v1.10.0

Affected Resource(s)

Please list the resources as a list, for example:

• kubernetes_cluster_role_binding
• kubernetes_role_binding

Terraform Configuration Files

resource "kubernetes_cluster_role_binding" "developer_cluster" {
  metadata {
    name = "company-developer"
  }
  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "ClusterRole"
    name      = kubernetes_cluster_role.developer_cluster.metadata.0.name
  }
  subject {
    api_group = "rbac.authorization.k8s.io"
    kind      = "Group"
    name      = "company:developer"
  }
}

resource "kubernetes_role_binding" "developer_namespace" {
  metadata {
    name      = "company-developer"
    namespace = kubernetes_namespace.app.metadata.0.name
  }
  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "ClusterRole"
    name      = kubernetes_cluster_role.developer_namespace.metadata.0.name
  }
  subject {
    api_group = "rbac.authorization.k8s.io"
    kind      = "Group"
    name      = "company:developer"
  }
}

Expected Behavior

The subject blocks of the role bindings should be created as per the config without a namespace.

Actual Behavior

The role bindings were created and the namespace field was added with a value of default.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

[antonosmond]

If it helps I ran with log level set to TRACE and noticed this in the logs:

2019/12/17 12:46:44 [WARN] Provider "kubernetes" produced an invalid plan for kubernetes_cluster_role_binding.developer_cluster, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .subject[0].namespace: planned value cty.StringVal("default") does not match config value cty.NullVal(cty.String)

2019/12/17 12:46:44 [WARN] Provider "kubernetes" produced an invalid plan for kubernetes_role_binding.developer_namespace, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .subject[0].namespace: planned value cty.StringVal("default") does not match config value cty.NullVal(cty.String)

[Ranger-X]

Same issue. Looks related with #713.
Terraform v0.12.21

• provider.kubernetes v1.11.1

[jharshman]

Same issue, same log as above when run with TF_LOG=TRACE.

• Terraform v0.12.6
• provider.kubernetes v1.11.3

[alex-karpenko]

Same issue, unwanted namespace attribute is present for Group kind.
Terraform v0.13.4
provider.kubernetes v1.13.2

[jeffreylutz]

Hi. I discovered a work-around. Even though the documentation says that for kind: Group, namespace is a property that is not available. If you set namespace="" for kind: Group, then the resultant clusterrolebinding for kind: Group doesn't have namespace as a property, as it should.

I'm using terraform v 0.12.28

Example:

resource "kubernetes_cluster_role_binding" "cluster-superusers" {
metadata {
name = "cluster-superusers"
}
role_ref {
api_group = "rbac.authorization.k8s.io"
kind = "ClusterRole"
name = "cluster-superusers"
}
subject {
kind = "User"
name = "admin"
api_group = "rbac.authorization.k8s.io"
}
subject {
kind = "ServiceAccount"
name = "default"
namespace = "kube-system"
}
subject {
kind = "Group"
name = "system:masters"
namespace = ""
api_group = "rbac.authorization.k8s.io"
}
}

[flmmartins]

I confirm this also happens for

terraform v0.13.5
hashicorp/kubernetes v1.13.3

[mozz-lx]

The same happens when kind User is specified. Terraform tries to add an undesired namespace.

 subject {
    kind      = "User"
    name      = "myuser"
    api_group = "rbac.authorization.k8s.io"
  }

output from the plan

  ~ subject {
            api_group = "rbac.authorization.k8s.io"
            kind      = "User"
            name      = "myuser"
          + namespace = "default"
        }

my terraform informaiton.
Terraform v0.12.29
provider.kubernetes v1.13.3

[spikewang]

Still happening with the latest Kubernetes provider 2.0.2. Also confirming that the workaround works with specifying:

namespace = ""

[ismailyenigul]

still happening with Kubernetes provider version = "2.5.1"

      + subject {
          + api_group = "rbac.authorization.k8s.io"
          + kind      = "Group"
          + name      = "opsadmin"
          + namespace = "default"
        }
    }

and namespace = "" still works

[timblaktu]

Still happening here for provider version 2.8.0, and namespace = "" still works.

[roeera]

+1

[lindhe]

@roeera Thanks for pitching in, but it's better to vote with 👍on the post since that gets tracked by GitHub and can be sorted on. so it's easier to prioritize :)

[stevehipwell]

I can't believe this still hasn't been fixed as it was reported almost 3 years ago. For the record the official docs have the following to say about setting the namespace incorrectly which should make this a high priority bug.

Namespace of the referenced object. If the object kind is non-namespace, such as "User" or "Group", and this value is not empty the Authorizer should report an error.

[richie-tt]

Issue still exists in provider v2.13.1

[ddmunhoz]

Still exists... 2023... v2.16.1

[sergialonsaco]

Still found this issue in provider 2.17.0.

[manuelnucci]

Still exists in v2.22.0

[sshawaxpo]

Still exists in v.2.26.0

[tomislater]

Still exists in v.2.32.0, I know, I know...

[wangycc]

OMG Still exists in v2.34.0, it’s almost 2025

[BBBmau]

are users still running into this bug?

Reason for asking is this: #2633 (review)

[richie-tt]

Issue still exists in provider v2.13.1

I abandoned Terraform a few years ago in favor of CDK and CloudFormation. This is a new chapter in my IT life. I really recommend CDK.

[stevehipwell]

@BBBmau the test on the PR you linked is using the namespace = "" workaround so it's not testing this bug; remove lines 15 & 22 from your config and try it again.

FYI yes it is still an issue, see the comment directly above yours.

[asaphe]

It's now the 23rd of April 2025 :-) and this still exists in version 2.36.0 of the provider.

the workaround works.