Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

structure of /v1/data/ in opa has changed with kube-mgmt 0.10-rc1 #51

Closed
rtoma opened this issue Oct 2, 2019 · 4 comments
Closed

structure of /v1/data/ in opa has changed with kube-mgmt 0.10-rc1 #51

rtoma opened this issue Oct 2, 2019 · 4 comments

Comments

@rtoma
Copy link

rtoma commented Oct 2, 2019

We sync kubernetes namespace data to OPA.

With kube-mgmt 0.9 the response of GET /v1/data/kubernetes/namespaces is like:

{
  "decision_id": "0330b1eb-2fc8-4f2f-befe-330b7bbe3032",
  "result": {
    "my-namespace": {
      "apiVersion": "v1",
      "kind": "Namespace",
      "metadata": {
...

With kube-mgmt 0.10-rc1 the response changed to:

{
  "result": {
    "": {                                                  # <-----------
      "my-namespace": {
        "apiVersion": "v1",
        "kind": "Namespace",
        "metadata": {
...

Note the empty-string hash key.

@tsandall
Copy link
Member

tsandall commented Oct 2, 2019

@rtoma can you share the flags you started kube-mgmt with and the version of Kubernetes you're running against? I'm not able to reproduce this against Kubernetes v1.13 or v1.15.

{
  "result": {
    "kubernetes": {
      "namespaces": {
        "default": {
          "apiVersion": "v1",
          "kind": "Namespace",
          "metadata": {
            "creationTimestamp": "2019-10-02T12:44:16Z",
            "name": "default",
            "resourceVersion": "150",
            "selfLink": "/api/v1/namespaces/default",
            "uid": "3ed489d0-0648-4476-be9d-376a5c5298eb"
          },
          "spec": {
            "finalizers": [
              "kubernetes"
            ]
          },
          "status": {
            "phase": "Active"
          }
        },
        "kube-node-lease": {
          "apiVersion": "v1",
          "kind": "Namespace",
          "metadata": {
            "creationTimestamp": "2019-10-02T12:44:12Z",
            "name": "kube-node-lease",
            "resourceVersion": "8",
            "selfLink": "/api/v1/namespaces/kube-node-lease",
            "uid": "28f5d5f2-d739-43c9-8591-e754f925f494"
          },
          "spec": {
            "finalizers": [
              "kubernetes"
            ]
          },
          "status": {
            "phase": "Active"
          }
        },

kube-mgmt args:

      - name: kube-mgmt
        image: openpolicyagent/kube-mgmt:0.10
        args:
        - --replicate-cluster=v1/namespaces

@rtoma
Copy link
Author

rtoma commented Oct 2, 2019

I have tested openpolicyagent/kube-mgmt:0.10-rc1 (b38f0386cfc1) on v1.13.7-gke.24 with flags:

          - --replicate=v1/namespaces
          - --replicate=v1/pods
          - --replicate=extensions/v1beta1/ingresses

I see you used a different OPA REST endpoint. I used /v1/data/kubernetes/namespaces and not /v1/data.

@tsandall
Copy link
Member

tsandall commented Oct 2, 2019

Ah, interesting. Your args should be --replicate-cluster=v1/namespaces not --replicate=.... The --replicate-cluster flag tells kube-mgmt the resource is cluster scoped while the --replicate flag tells kube-mgmt the resource is namespace scoped. It seems the new version of kube-mgmt behaves slightly differently here. Nonetheless, you'll want to use --replicate-cluster. See https://github.com/open-policy-agent/kube-mgmt#caching

RE: the OPA REST endpoint, whether you can query at /data or /data/kubernetes/namespaces etc. doesn't matter in this case (the underlying data is the same.)

If you're able to test out v0.10 with the updated flag and let me know that would great (but I understand if you've got other things to do :D)

@rtoma
Copy link
Author

rtoma commented Oct 17, 2019

Verified with kube-mgmt:0.10 with --replicate-cluster=v1/namespaces and everything is fine. Closing.

@rtoma rtoma closed this as completed Oct 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants