-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Add one/many path templating support for AuthPolicy #50365
Conversation
Skipping CI for Draft Pull Request. |
😊 Welcome @jaellio! This is either your first contribution to the Istio istio repo, or it's been You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines Thanks for contributing! Courtesy of your friendly welcome wagon. |
/test all |
8d0a246
to
8b38e95
Compare
/test all |
@@ -399,6 +399,17 @@ func (g pathGenerator) permission(key, value string, forTCP bool) (*rbacpb.Permi | |||
return nil, fmt.Errorf("%q is HTTP only", key) | |||
} | |||
|
|||
// TODO(jaellio): Should we interpret the path as a PathMatcher if it is an invalid or unsupported by Istio PathTemplate? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@michaelbannister what are your initial thoughts on this? For my initial draft I didn't add any logic to disallow invalid or unsupported templating. Wanted to get this out for review ASAP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know – is there a general philosophy that Istio applies regarding invalid config? As a user I'd rather be told early that my authorization policy is broken or will never match a path, than spend ages debugging it at runtime, so I'd be in favour of fairly strict validation and failing with a meaningful error, rather than generating a rule which won't match anything.
But would such an error get surfaced to the client through a validation webhook? I suspect it may depend on how istio's been set up…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should block in validation, and make this an error probably
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The hard part about error is that previously allowed policies could now be blocked. That may be acceptable though due to a low likelihood?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Keith, I was concerned about disallowing previously allowed paths/policies. However, those paths might technically have been invalid so this might be an acceptable regression.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like validation was pushed up @jaellio?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added basic validation to ensure that if a path contains a support path template ({*}
or {**}
) it must also not contain *
or **
or any named variable ({path}
, {path=*}
, or {path=**}
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know – is there a general philosophy that Istio applies regarding invalid config? As a user I'd rather be told early that my authorization policy is broken or will never match a path, than spend ages debugging it at runtime, so I'd be in favour of fairly strict validation and failing with a meaningful error, rather than generating a rule which won't match anything.
But would such an error get surfaced to the client through a validation webhook? I suspect it may depend on how istio's been set up…
Agree - invalid should be reflected in resource status at least. As we move to CEL validation - not sure if all validations will be possible in CEL and it may be best to use status consistently.
Since this is a very envoy-specific feature - may be worth adopting the same doc and validations that envoy makes. And to confirm - is the syntax in this PR identical to the syntax used by Envoy, or did we make any subtle changes ?
Marking as ready for review. Would appreciate feedback on the general approach. Hold on merging until I have added integration tests. |
8b38e95
to
c8781df
Compare
// Ex: "/foo/{*" is not a valid PathTemplate. | ||
// Ex: "/foo/{bar}" is an unsupported PathTemplate. | ||
// | ||
// Should we disallow the use of `*` and `**` in the path if it is a PathTemplate (the path contains `{*}` or `{**}`, and `*` or `**`)? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be inclined towards disallowing it. I think the chances of someone trying to match a path that genuinely has a *
in it, and using PathTemplate matchers as well, are vanishingly small, and if they do exist they will raise a feature request to have the validation relaxed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@michaelbannister added logic to disallow the use of *
and **
with path templating. Did not add the logic to check for invalid path templates (i.e. /foo/{*
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good. I think we need validation (pkg/config/validation/validation.go) and integration tests
@@ -399,6 +399,17 @@ func (g pathGenerator) permission(key, value string, forTCP bool) (*rbacpb.Permi | |||
return nil, fmt.Errorf("%q is HTTP only", key) | |||
} | |||
|
|||
// TODO(jaellio): Should we interpret the path as a PathMatcher if it is an invalid or unsupported by Istio PathTemplate? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should block in validation, and make this an error probably
214c135
to
0593921
Compare
/test integ-basic-arm64_istio |
/test unit-tests-arm64 |
Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
a to b requests - Adds a name to typed extension config for uri template Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
Added additional path template validation. Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
49704e8
to
0146c61
Compare
multiple matches Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM aside from some nits
pilot/pkg/security/authz/builder/testdata/http/allow-full-rule-in.yaml
Outdated
Show resolved
Hide resolved
42205a0
to
15c96fb
Compare
}, | ||
// Test matches for `/store/{**}/cart` | ||
{ | ||
path: "/store//cart", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this one is interesting because with https://istio.io/latest/docs/reference/config/security/normalization/#3-multiple-forward-slashes---etc this would not match
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep; we should update that page or the docs for this field/feature with a warning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@howardjohn Created a PR to clarify behavior of MERG_SLASHES with {**}
https://github.com/istio/istio.io/pull/14954/files
rules: | ||
- to: | ||
- operation: | ||
paths: ["/allow/admin/{**}", "/foo/{*}/bar/{**}.txt", "/store/{**}/cart"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we test an inline {*}
? like /abc{*}efg/
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also do we even want to support these inline ones? or just whole segments?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought envoy only allows ** as the last component ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It has to be the last operator, not the last component of the path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a test with url-encoded *, {, etc ?
Is this something based on some prior art - or another Envoy NIH ? I assume
we confirmed this is going to be a long term supported API on their side.
If we didn't have the K8SGateway mode mixed and the waypoints - I wouldn't
mind this too much.
…On Fri, Apr 19, 2024, 14:31 Jackie Elliott ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In tests/integration/security/testdata/authz/path-templating.yaml.tmpl
<#50365 (comment)>:
> @@ -0,0 +1,13 @@
+apiVersion: security.istio.io/v1beta1
+kind: AuthorizationPolicy
+metadata:
+ name: {{ .To.ServiceName }}
+spec:
+ selector:
+ matchLabels:
+ "app": "{{ .To.ServiceName }}"
+ action: ALLOW
+ rules:
+ - to:
+ - operation:
+ paths: ["/allow/admin/{**}", "/foo/{*}/bar/{**}.txt", "/store/{**}/cart"]
It has to be the last operator, not the last component of the path.
—
Reply to this email directly, view it on GitHub
<#50365 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUR2SIK37N7IH2LUVO3GDY6FWK3AVCNFSM6AAAAABGBGE6PGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDAMJSGIZDCNBRGY>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
template it cannot have the following chars outside of a supported template: {, }, and *. Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just one small validation improvement I think we can use and a question
pilot/pkg/security/authz/builder/testdata/http/allow-path-out.yaml
Outdated
Show resolved
Hide resolved
pkg/config/security/security.go
Outdated
func CheckValidPathTemplate(key string, paths []string) error { | ||
for _, path := range paths { | ||
// If path does not contain any path templates, skip the check. | ||
if !ContainsPathTemplate(path) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we want to remove this if now, so we would reject something like /foo/{name}/bar
.
Though we will need to improve the Contains(*)
check since that is valid for !ContainsPathTemplate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
template operators in path. Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
9c5091f
to
2b3cb4c
Compare
Follow up to istio/istio#50365 (comment) Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
Follow up to istio/istio#50365 (comment) Signed-off-by: Jackie Elliott <jaellio@microsoft.com>
@@ -100,6 +105,36 @@ func CheckEmptyValues(key string, values []string) error { | |||
return nil | |||
} | |||
|
|||
func CheckValidPathTemplate(key string, paths []string) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving this into pilot/pkg/security/authz/matcher/template.go will look more cohesive.
Please provide a description of this PR:
Updates
paths
andnotPaths
in the AuthorizationPolicy resource to support a limited set of templating based on envoy's uri templating.#16585
Adds support for:
{*}
{**}
If a path contains
{*}
or{**}
it will be interpreted as a uri template rather than a string match.{*}
will be converted to*
and{**}
will be convert to**
when applied in the envoy config.Open questions:
{}
,{*
, etc) should we return an error or interpret the path as a string match?*
or**
(invalid chars in uris, but valid for paths and notPaths) and supported templates ({*}
and{**}
), should we return an error, interpret the path as a string match, or interpret the path as a uri template (which might result in unintended behavior since*
and**
will be interpreted as uri templates)?Todo: