Updated rules for CRD and mixer #560
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andraxylia The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
| @@ -8,6 +8,12 @@ apiVersion: rbac.authorization.k8s.io/v1beta1 | |||
| metadata: | |||
| name: istio-pilot | |||
| rules: | |||
| - apiGroups: ["config.istio.io"] | |||
| resources: ["istiokinds"] | |||
There was a problem hiding this comment.
put * star here for future-proofing
| namespace: default | ||
| roleRef: | ||
| kind: ClusterRole | ||
| name: istio-pilot |
There was a problem hiding this comment.
this is really a big hack. @mandarjog or some mixer hacker to get the right permissions.
There was a problem hiding this comment.
Yes, this will be addressed separately.
| - apiGroups: ["config.istio.io"] | ||
| resources: ["istiokinds"] | ||
| verbs: ["get", "list", "watch"] | ||
| - apiGroups: ["apiextensions.k8s.io"] |
There was a problem hiding this comment.
Do we have different roles for creating new Istio config types (via CRD) vs. creating new instances of these types? The former would be limited to installation time and the latter restricted to specific components by type.
There was a problem hiding this comment.
each component is responsible for installing its config for now
There was a problem hiding this comment.
I figured that was probably the case. I guess we can reconsider splitting that out later once new Istio CRD types are stabilized.
* Updated rules for CRD and mixer * Future proof? * Put * instead of istiokinds Former-commit-id: 412d361
* Updated rules for CRD and mixer * Future proof? * Put * instead of istiokinds Former-commit-id: 412d361
This change adds support for creating mixer rules with istioctl. It
supports "create" and "get" as subcommands to "istioctl mixer
rule". The mixer API server address is set with the
ISTIO_MIXER_API_SERVER environment variable for easy integration into
istio demo and smoke test as well as with "-m/--mixer" flag.
Example usage:
$ export ISTIO_MIXER_API_SERVER=localhost:9094
$ cat rules.yml
subject: namespace:ns
revision: "2022"
rules:
- aspects:
- kind: denials
$ istioctl mixer rule create global myservice.ns.svc.cluster.local -f rules.yml
$ istioctl mixer rule get global myservice.ns.svc.cluster.local
revision: "2022"
rules:
- aspects:
- kind: denials
subject: namespace:ns
There is much room for improvement in the istioctl and API server space:
1) Unify mixer and proxy API servers
2) Unify proxy and mixer resource file format so that
"istioctl create -f <file>" can be used to create any
istio resource, e.g. DestinationPolicy, RouteRule, MixerRule.
3) Move API server's gRPC and REST API definitions into istio.io/api
instead of spreading it across multiple component repos.
4) istioctl auth to API servers
* Updated rules for CRD and mixer * Future proof? * Put * instead of istiokinds Former-commit-id: 412d361
* RemoveResponseHeaders should be a repeated string instead of a map Signed-off-by: Christopher M. Luciano <cmluciano@us.ibm.com> * Add removeResponseHeaders generated code Signed-off-by: Christopher M. Luciano <cmluciano@us.ibm.com>
Signed-off-by: Juraci Paixão Kröhling <jpkroehling@redhat.com>
Fixes #550
After pilot and mixer images are updated, we need a follow up to remove TPRs, add a mixer role and fine-grained rules for mixer.