I want to create a rule in the Istio authorization:
- to:
- operation:
methods: [ "POST" ]
paths: [ "/data/api/v1/departments/*/users/*/position" ]
when:
- key: request.auth.claims[resource_access][roles]
values: [ "edit" ]
so I want to use path variables here (in places with '*'). What should I put instead of '*' to make it working?
It doesn't work in the current setup.
I get 'RBAC denied', I have a role 'edit' and path to that role is okay. It works fine for endpoints without '*' signs
Posting this answer as a community wiki as similar question has been already answered here:
Stackoverflow.com: Answer: Istio authorization - Pattern matching in Istio 'paths' field
Part of the question:
- operation:
methods: ["PUT"]
paths: ["/my-service/docs/*/activate/*"]
Answer:
According to istio documentation:
Rule
Rule matches requests from a list of sources that perform a list of
operations subject to a list of conditions. A match occurs when at
least one source, operation and condition matches the request. An
empty rule is always matched.
Any string field in the rule supports Exact, Prefix, Suffix and
Presence match:
Exact match: “abc” will match on value “abc”.
Prefix match: “abc*” will match on value “abc” and “abcd”.
Suffix match: “*abc” will match on value “abc” and “xabc”.
Presence match: “*” will match when value is not empty.
So Authorization Policy does support wildcard, but I think the issue is with the */activate/* path, because paths can use wildcards only at the start, end or whole string, double wildcard just doesn't work.
There are related open github issues about that:
https://github.com/istio/istio/issues/16585
https://github.com/istio/istio/issues/25021
Related
I'm trying to filter the event log based on regex but I'm unable to figure it out yet.
Scenario 1): I want to match the full line starting with Account Name but I don't want to match the line if it has - (hyphen) only that. But it should match -test-user.
I tried (Account Name:.*(!-).*) but it isn't working.
Content:
Account Name: -
Account Name: testing
Scenario 2): I want to try matching the second Account name line with or without hyphen in the Account For Which Logon Failed section and not from Subject section.
I tried (Account Name:.*){2} but it isn't working.
Content:
Account Name: -
Account Name: testing
Scenario 3): Combine both Scenario, Match the second Account name line but only it has no - (hyphen). If the second Account name has only hyphen then don't match anything but it should match -test-user.
I'm trying to learn here that's why I want to figure out all three scenario. Eventually I'll use only the last one.
Here is the full content:
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: testing
See if this answers your question
/Account Name:\s*[^-][a-z]+$/gm
You can find the working example here
if you want to match all the special characters excluding - then you can use
/Account Name:\s*[a-zA-Z0-9~##$^&*()_+=[\]{}|\\,.?:<>'"\/;`%]+.*$/gm
You can include any special character in the list that you want inside []
updated example
I've two WSO2 IS 5.7.0 environments. The id tokens returned by https://localhost:9443/oauth2/token have slight difference. the first environment: the 'groups' attribute has values like the following:
"groups": [
"FOTA_WEB_View_User",
"FOTA_Engineer",
"FOTA_Manager",
"FOTA_WEB_Admin",
"Internal/everyone",
"_login",
"FOTA_APP"
]
but in the second environment, the 'groups' attribute has values like the following：
"groups": "BDA-AA-Flameout-Download,BDA-Diag-TempSensor-Download,BDA_Admin,BDA-AA-Superknock-Download,Internal/everyone,_login,BDA-AA-Flameout-View,BDA-AA-Superknock-View"
Actually, the first is expected.
The configration seems the same, i.e. add a new service provider, and then add
Requested Claims. see below pictures.
A possible way to happen this is not configuring the MultiAttributeSeparator property in user-mgt.xml (/repository/conf/user-mgt.xml) file. This property is available in all UserStoreManager classes. In this case we need to set the value for the MultiAttributeSeparator property to comma (,) in the JDBCUserStoreManager properties since the user store is a JDBC database (MYSQL).
I am building an Angular application and trying to figure out the way to write ngsw-config.json -file in order to define rules for service worker.
I assumed that regex would be recognized as regex in configuration file and not interpret as normal characters / text automatically, but it was not so. I have for example following piece of a code:
"name": "authentication",
"urls": [
"/login",
"/.*authentication.*"
],
part .* is not in my understanding recognized as regex (regex meaning in this case that any path that has text "authentication" would fall into this category, right?). This piece of a configuration tries to prevent service worker to take a lead in these two cases, it works with /login, but not with authentication part.
Question:
Can I somehow modify my file to make it recognize regex definitions?
According to the documentation at https://angular.io/guide/service-worker-config
you can use a limited glob format.
I don't know what kind of url you want to match.
Option: If you want to match a url like /foo/bar/authentication/foo2/bar2 you could use:
"name": "authentication",
"urls": [
"/login",
"/**/authentication/**/*"
],
Option: If you want to match a url like /foo/bar/something-authentication-otherthing/foo2/bar2 you could use:
"name": "authentication",
"urls": [
"/login",
"/**/*authentication*/**/*"
],
I was wondering if there's a way to perform multiple exact matches within envoy ?
For e.g. interested in directing traffic to two different clusters based on a header attribute,
- match:
prefix: "/service/2"
headers:
- name: X-SOME-TAG
exact_match: "SomeString"
This works as expected but is it possible to specify a list of strings in a list to match against in exact_match e.g. exact_match: ["some_string", another"] ?
I can also write it as,
- match:
prefix: "/service/2"
headers:
- name: X-SOME-TAG
exact_match: "some_string"
route:
cluster: service1
- match:
prefix: "/service/2"
headers:
- name: X-SOME-TAG
exact_match: "another"
route:
cluster: service1
But not sure, if this is un-necessarily verbose and the right way.
Or do I have to use something like regex_match for this or patterns ?
Sorry, I just haven't been able to get this to work, testing with the example on the envoy documentation for front-proxies, hence figured would put this out there. Thanks!
I'm not sure based on your question whether you want to AND the matches or OR them. If you want both to have to match (AND), both matches need to be under the same - match: section, otherwise, make them in seperate - match: sections. The second example you provided above would be the equivalent of an OR, i.e. "if X-SOME-TAG == "some_string" OR X-SOME-TAG == "another", route to service1.
You can try:
- match:
prefix: "/service/2"
headers:
- name: X-SOME-TAG
safe_regex_match:
google_re2: {}
regex: "some_string|another"
route:
cluster: service1
I have a policy that looks like:
["starts-with", "$x-amz-meta-tag", ""]
Per the docs:
To configure the POST policy to allow any content within a form field, use starts-with with an empty value (""). This example allows any value for success_action_redirect:
["starts-with", "$success_action_redirect", ""]
The problem is you can send an empty string up and this will pass.
Is there a way to configure the policy so that it has to be x length or at least not an empty string?
There isn't, but...
The option you have is to enforce the validation in your application, set the value in the form as a hidden field, and then include a ["eq", "$x-amz-meta-tag", "the same string you embedded in the form"] condition in your policy. Since the policy that is signed actually includes the required value, a user can't modify that value and submit the form without a policy violation occurring, denying the upload.