-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Better logging and internal user handling for operator privileges #79331
Changes from 2 commits
d97a18d
376325b
a4c936c
abc1f1c
649ba6d
e94b5b7
0898932
ae2ab3c
a1f1d0a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -29,7 +29,6 @@ | |
import org.elasticsearch.xpack.core.security.authc.Authentication; | ||
import org.elasticsearch.xpack.core.security.authc.esnative.NativeRealmSettings; | ||
import org.elasticsearch.xpack.core.security.authc.file.FileRealmSettings; | ||
import org.elasticsearch.xpack.core.security.user.User; | ||
import org.elasticsearch.xpack.security.authc.esnative.ReservedRealm; | ||
|
||
import java.io.IOException; | ||
|
@@ -65,13 +64,6 @@ public FileOperatorUsersStore(Environment env, ResourceWatcherService watcherSer | |
} | ||
|
||
public boolean isOperatorUser(Authentication authentication) { | ||
if (authentication.getUser().isRunAs()) { | ||
return false; | ||
} else if (User.isInternal(authentication.getUser())) { | ||
// Internal user are considered operator users | ||
return true; | ||
} | ||
|
||
// Other than realm name, other criteria must always be an exact match for the user to be an operator. | ||
// Realm name of a descriptor can be null. When it is null, it is ignored for comparison. | ||
// If not null, it will be compared exactly as well. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Given the intent of this PR, I think we should have some trace logging when checking for a matching group below. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, I added a trace log for when the result is |
||
|
@@ -217,19 +209,24 @@ public static OperatorUsersDescriptor parseFile(Path file, Logger logger) { | |
} else { | ||
logger.debug("Reading operator users file [{}]", file.toAbsolutePath()); | ||
try (InputStream in = Files.newInputStream(file, StandardOpenOption.READ)) { | ||
return parseConfig(in); | ||
final OperatorUsersDescriptor operatorUsersDescriptor = parseConfig(in); | ||
logger.info("parsed [{}] group(s) with a total of [{}] operator user(s) from file [{}]", | ||
operatorUsersDescriptor.groups.size(), | ||
operatorUsersDescriptor.groups.stream().mapToLong(g -> g.usernames.size()).sum(), | ||
file.toAbsolutePath()); | ||
logger.trace("operator user descriptor: [{}]", operatorUsersDescriptor); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes I agree it is better to be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we need to deal with the cloud file refresh problem separately. It's been an issue for years, and I think we need to put something into the resource watching infrastructure that can check if the file contents have really changed. I'll work on something. |
||
return operatorUsersDescriptor; | ||
} catch (IOException | RuntimeException e) { | ||
logger.error(new ParameterizedMessage("Failed to parse operator users file [{}].", file), e); | ||
throw new ElasticsearchParseException("Error parsing operator users file [{}]", e, file.toAbsolutePath()); | ||
} | ||
} | ||
} | ||
|
||
public static OperatorUsersDescriptor parseConfig(InputStream in) throws IOException { | ||
// package method for testing | ||
static OperatorUsersDescriptor parseConfig(InputStream in) throws IOException { | ||
try (XContentParser parser = yamlParser(in)) { | ||
final OperatorUsersDescriptor operatorUsersDescriptor = OPERATOR_USER_PARSER.parse(parser, null); | ||
logger.trace("Parsed: [{}]", operatorUsersDescriptor); | ||
return operatorUsersDescriptor; | ||
return OPERATOR_USER_PARSER.parse(parser, null); | ||
} | ||
} | ||
|
||
|
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 "context" doesn't seem very clear to me.
What exactly is it trying to say?
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 didn't do what I expected. Sorry for the confusion. I was meant to add it at the end of the error message. So eorror message says something like "... this action is granted by .. and operator privileges". It should work now after the latest push. Let me know if you are OK with the approach.
Btw, I added it because I'd like the error with operator privileges to present in the main error message which is more prominent in logging and response.