hashicorp / terraform-provider-kubernetes

Terraform Kubernetes provider
https://www.terraform.io/docs/providers/kubernetes/
Mozilla Public License 2.0
1.6k stars 979 forks source link

kubernetes_cluster_role_binding & kubernetes_role_binding adding namespace when subject kind is Group #710

Open antonosmond opened 4 years ago

antonosmond commented 4 years ago

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

Affected Resource(s)

Please list the resources as a list, for example:

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 commented 4 years ago

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 commented 4 years ago

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

jharshman commented 4 years ago

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

alex-karpenko commented 4 years ago

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

jeffreylutz commented 4 years ago

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 commented 3 years ago

I confirm this also happens for

terraform v0.13.5 hashicorp/kubernetes v1.13.3

mozz-lx commented 3 years ago

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 commented 3 years ago

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

namespace = ""
ismailyenigul commented 3 years ago

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 commented 2 years ago

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

roeera commented 2 years ago

+1

lindhe commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

Issue still exists in provider v2.13.1

ddmunhoz commented 1 year ago

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

sergialonsaco commented 1 year ago

Still found this issue in provider 2.17.0.

manuelnucci commented 1 year ago

Still exists in v2.22.0

sshawaxpo commented 8 months ago

Still exists in v.2.26.0

tomislater commented 1 month ago

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