Support for Istio Mixer's Conditions Check (#1403) #1606
Conversation
| requestPath, | ||
| targetService, | ||
|
|
||
| sourceLabelApp, |
There was a problem hiding this comment.
@adleong In the original code, this would send the values of these things as part of the dictionary. My understanding is that the dictionary should only contain the keys to be resolved by Mixer. Is this intentional?
be6ba2f to
85d743e
Compare
f819ce4 to
10f416d
Compare
c461bc3 to
c58600b
Compare
dc4e4a0 to
a2f03f7
Compare
a2f03f7 to
c8c4ab6
Compare
| @@ -0,0 +1,5 @@ | |||
| # Google RPC | |||
There was a problem hiding this comment.
The "g" in gRPC apparently no longer stands for Google :)
There was a problem hiding this comment.
This was copied verbatim from https://github.com/googleapis/googleapis/blob/master/google/rpc/README.md#google-rpc so I think we should keep it but... it had actually never occurred to me that the g stood for "Google", I always thought it was something like "generalised" :P
There was a problem hiding this comment.
Exciting to see linkerd implement more with Mixer! I'm planning to come back through with a more detailed review, but some high level comments:
- The cache should store both positive and negative results, not just negative. It was unclear to me if your comment was about the cache in linkerd as you've implemented it, or the cache as it exists in https://github.com/istio/mixerclient; the cache in Mixerclient caches both positive and negative results.
- You don't need to produce some of the attributes you're providing. Here's the set of attributes that Envoy produces in a stock Istio deployment. In particular, kubernetes specific stuff like
source.labels,source.verson, etc. is derived by Mixer and doesn't have to be retrieved by the proxy. Envoy takes no dependency on the k8s API server in a normal Istio deployment. You can see the attributes Mixer produces on k8s today in that same document I linked, the next CRD down.
| private def mkAttributesUpdate(customAttributeNames: Seq[String], attributes: Seq[IstioAttribute[_]]) = { | ||
|
|
||
| // TODO: eventually we should not have to send istioGlobalDict over the wire, | ||
| // and instead use positive index integers |
There was a problem hiding this comment.
I'm ignorant about Scala: when you retrieve indices in dictionary with indexOf, where're you flipping the index around to be negative? You want them to be negative since you're indexing into the local dictionary instead of the global one.
There was a problem hiding this comment.
Thanks so much, Zack!
- Uhm.. the comment was about
mixerclient, I probably misread something on the code. This iteration doesn't have a cache yet, but I will make sure to follow the same logic when we add it 👍 - This is brilliant, thank you. As I understand it, our first integration code was tested against an early alpha release and as everything was moving so fast we decided to send a lot of stuff just to make sure we didn't miss on anything that would become important or mandatory. I'll change it to the list you provided!
- Our current integration runs against an older schema that didn't have the negative index logic. I'll update the schemas as we move our integration to 0.2.x
c8c4ab6 to
b0d38a5
Compare
b9dd7df to
1525179
Compare
|
|
||
| def targetServiceIn(istioPath: Path): Option[String] = { | ||
| val pathServiceIndex = istioPath.elems.size - 3 | ||
| if (pathServiceIndex > 0) { |
There was a problem hiding this comment.
Should this be >= 0? I mean, element 0 should always be $ or # but I assume this is intended to just avoid index out of bounds.
There was a problem hiding this comment.
This is pretty much a panic situation so I'm not sure if it matters, but I will add the =
| } | ||
| } | ||
|
|
||
| def targetServiceIn(istioPath: Path): Option[String] = { |
There was a problem hiding this comment.
It would be helpful to have a comment with the expected structure of path so that these offsets are easier to understand.
3c58503 to
db957e8
Compare
db957e8 to
dc8f1b5
Compare
|
This should be merge-able, waiting for the final 👍 to merge |
## 1.3.1 2017-10-24 * Kubernetes * Fixed a failure to update routing data after restarting watches (#1674). * Ensured that Kubernetes API watch events earlier than the current state are ignored (#1681). * Added support for Istio Mixer precondition checks (#1606). * Removed spurious error message logging from Consul namer (#1682). * Changed DNS SRV record namer to use system DNS resolver configuration (#1679). * Added `timestampHeader` configuration to support New Relic request queue (#1672).
This implementation builds on the original Istio integration work, extending our Mixer integration to not only send reporting data but also checking for preconditions.
The initial design assumed that this check could be done at the
Identifier, but it turns out that to get thetarget.serviceattribute we need it to be much later in the processing chain. We then refactored what was known as theIstioLoggerinto anRequestAuthorizationthat performs such check.The actual check added: 54ba9ad#diff-1d26b6a6caa59bb04f9815bbca98dd76R22
Design Rationale
Istio allows for operators to define preconditions that must be met before a request is sent to a service. These preconditions are defined based on attributes. As per #1403, we want to add this feature to an Istio + Linkerd deployment.
The way this is supposed to work is that the proxy should send the request attributes to the check request API and, depending on the result, either forward the request to the underlying service or reject the connection altogether.
The way Istio's vanilla proxy implements the check is by first checking against a cache of pre-computed results. The cache is indexed by a hash of each attribute from the request. The cache is only used to prevent calls that are known to fail the check, and not enabled by default. Our implementation currently doesn't cache anything.