Skip to content
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

[FTR] enable roles management testing for Observability project #196514

Merged
Merged
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ export interface KibanaRoleDescriptors {
}

const throwIfRoleNotSet = (role: string, customRole: string, roleDescriptors: Map<string, any>) => {
if (role === customRole && !roleDescriptors.has(customRole)) {
if (role === customRole && !roleDescriptors.get(customRole)) {
throw new Error(
`Set privileges for '${customRole}' using 'samlAuth.setCustomRole' before authentication.`
);
Expand Down Expand Up @@ -179,7 +179,7 @@ export function SamlAuthProvider({ getService }: FtrProviderContext) {
if (!isCustomRoleEnabled) {
throw new Error(`Custom roles are not supported for the current deployment`);
}
log.debug(`Updating role ${CUSTOM_ROLE}`);
log.debug(`Updating role '${CUSTOM_ROLE}'`);
const adminCookieHeader = await getAdminCredentials();

const customRoleDescriptors = {
Expand All @@ -199,6 +199,28 @@ export function SamlAuthProvider({ getService }: FtrProviderContext) {
supportedRoleDescriptors.set(CUSTOM_ROLE, customRoleDescriptors);
},

async deleteCustomRole() {
if (!isCustomRoleEnabled) {
throw new Error(`Custom roles are not supported for the current deployment`);
}

if (supportedRoleDescriptors.get(CUSTOM_ROLE)) {
log.debug(`Deleting role '${CUSTOM_ROLE}'`);
const adminCookieHeader = await getAdminCredentials();

const { status } = await supertestWithoutAuth
.delete(`/api/security/role/${CUSTOM_ROLE}`)
.set(INTERNAL_REQUEST_HEADERS)
.set(adminCookieHeader);

expect(status).to.be(204);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the status is not a 204, is it still possible that it was indeed deleted?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting point.
I guess both create and delete operations are tested within security plugin testing scope. 204 status is successful request by design, so I don't think we need an extra ES query to validate Kibana APIs did their job.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw I checked that it is deleted via UI, but I think we are good to rely on status code only

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, I was just wondering if that null assignment within the map symbol below could be a problem if the 204 check fails, but the item was actually deleted, then the map would be out of date and could be a difficult bug to track down.
But if you think it's a non-issue, I'm good with it.

Copy link
Member Author

@dmlemeshko dmlemeshko Oct 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha, I didn't relate it to the supportedRoleDescriptors not being updated. You are right, we should re-set it for the following test file that might use custom roles as well. Let me have a look

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved before actual delete call bcfc49f


// Resetting descriptors for the custom role
supportedRoleDescriptors.set(CUSTOM_ROLE, null);
log.debug(`'${CUSTOM_ROLE}' descriptors were reset`);
}
},

getCommonRequestHeader() {
return COMMON_REQUEST_HEADERS;
},
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -34,8 +34,18 @@ const getDefaultServerlessRole = (projectType: string) => {
}
};

const isRoleManagementExplicitlyEnabled = (args: string[]): boolean => {
const roleManagementArg = args.find((arg) =>
arg.startsWith('--xpack.security.roleManagementEnabled=')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may simplify things to pull in the getopts package for parsing these. I see --serverless is parsed similarly elsewhere, so don't see a need to change it now, but making a note in case we refactor later.

);

// Return true if the value is explicitly set to 'true', otherwise false
return roleManagementArg?.split('=')[1] === 'true' || false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is true a string literal, but false is a boolean?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get that coercion will make true become a boolean, but that's if coercion is used.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we are looking for the exact --xpack.security.roleManagementEnabled=true match in Kibana server arguments to understand if roles management was explicitly enabled. I believe Kibana won't start if you try to pass this flag with something other than true or false

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean only 'true' is expected to enable the functionality, so I set flag to false for any other case (including argument is completely missing)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the return type of boolean, is only actually a boolean when it's false.
So if it's the string literal 'true' and not a boolean true, it seems like the return type should be false || 'true', and not boolean right?

I guess I'm used to seeing a boolean return type with all return calls being an actual boolean, not a string literal depending on type coercion.

Perhaps it's just a nit at this point.

Copy link
Member Author

@dmlemeshko dmlemeshko Oct 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you can start Kibana with --xpack.security.roleManagementEnabled='true', schema validation won't allow it. I don't try validate the cases for Kibana server, I believe FTR won't even start if literal 'true' or 'false' will be in arguments

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was right, there is no way to face literal 'true' in place:

 proc [kibana] [2024-10-16T14:13:30.865+02:00][INFO ][root] Kibana is shutting down {"service":{"node":{"roles":["background_tasks","ui"]}}}
 proc [kibana] [2024-10-16T14:13:30.884+02:00][FATAL][root] Reason: [config validation of [xpack.security].roleManagementEnabled]: expected value of type [boolean] but got [string]
 proc [kibana] Error: [config validation of [xpack.security].roleManagementEnabled]: expected value of type [boolean] but got [string]
 proc [kibana]     at ObjectType.validate (type.ts:171:13)
 proc [kibana]     at ConfigService.validateAtPath (config_service.ts:334:19)
 proc [kibana]     at config_service.ts:354:28
 proc [kibana]     at /Users/dmle/github/kibana/node_modules/rxjs/src/internal/operators/map.ts:58:33
 proc [kibana]     at OperatorSubscriber._this._next (/Users/dmle/github/kibana/node_modules/rxjs/src/internal/operators/OperatorSubscriber.ts:70:13)

};

export class ServerlessAuthProvider implements AuthProvider {
private readonly projectType: string;
private readonly roleManagementEnabled: boolean;
private readonly rolesDefinitionPath: string;

constructor(config: Config) {
Expand All @@ -45,6 +55,10 @@ export class ServerlessAuthProvider implements AuthProvider {
return acc + (match ? match[1] : '');
}, '') as ServerlessProjectType;

// Indicates whether role management was explicitly enabled using
// the `--xpack.security.roleManagementEnabled=true` flag.
this.roleManagementEnabled = isRoleManagementExplicitlyEnabled(kbnServerArgs);

if (!isServerlessProjectType(this.projectType)) {
throw new Error(`Unsupported serverless projectType: ${this.projectType}`);
}
Expand All @@ -70,7 +84,9 @@ export class ServerlessAuthProvider implements AuthProvider {
}

isCustomRoleEnabled() {
return projectTypesWithCustomRolesEnabled.includes(this.projectType);
return (
projectTypesWithCustomRolesEnabled.includes(this.projectType) || this.roleManagementEnabled
);
}

getCustomRole() {
Expand Down
8 changes: 7 additions & 1 deletion x-pack/test_serverless/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -207,6 +207,8 @@ describe("my internal APIs test suite", async function() {
With custom native roles now enabled for the Security and Search projects on MKI, the FTR supports
defining and authenticating with custom roles in both UI functional tests and API integration tests.

To test role management within the Observability project, you can execute the tests using the existing [config.feature_flags.ts](x-pack/test_serverless/functional/test_suites/observability/config.feature_flags.ts), where this functionality is explicitly enabled. Though the config is not run on MKI, it provides the ability to test custom roles in Kibana CI before the functionality is enabled in MKI. When roles management is enabled on MKI, these tests can be migrated to the regular FTR config and will be run on MKI.

For compatibility with MKI, the role name `customRole` is reserved for use in tests. The test user is automatically assigned to this role, but before logging in via the browser, generating a cookie header, or creating an API key in each test suite, the role’s privileges must be updated.

Note: We are still working on a solution to run these tests against MKI. In the meantime, please tag the suite with `skipMKI`.
Expand All @@ -229,6 +231,9 @@ await samlAuth.setCustomRole({
});
// Then, log in via the browser as a user with the newly defined privileges
await pageObjects.svlCommonPage.loginWithCustomRole();

// Make sure to delete the custom role in the 'after' hook
await samlAuth.deleteCustomRole();
```

FTR api_integration test example:
Expand All @@ -251,8 +256,9 @@ await samlAuth.setCustomRole({
// Then, generate an API key with the newly defined privileges
const roleAuthc = await samlAuth.createM2mApiKeyWithRoleScope('customRole');

// Remember to invalidate the API key after use
// Remember to invalidate the API key after use and delete the custom role
await samlAuth.invalidateM2mApiKeyWithRoleScope(roleAuthc);
await samlAuth.deleteCustomRole();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So now the devs have to make two extra calls to finish?
Possible to make this a single call?

Copy link
Member Author

@dmlemeshko dmlemeshko Oct 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need to combine it.

There is nothing new in the workflow: API key and Kibana role are 2 different entities and we already handle "cleaning" in stateful separately. In theory API key is still valid after role deletion and can be used on its own.

But now I realised it makes sense to delete cached cookie for custom role whenever setCustomRole or deleteCustomRole is called. Cookies are cached per role on the first call to speedup test execution, but as custom role is re-created we need to regenerate cookie as well. I will test it (maybe cookie will remains valid with new privileges in place) and address in the new PR

Copy link
Member Author

@dmlemeshko dmlemeshko Oct 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small fix dbdcd59

tl; dr; generated cookie remains valid after role is re-created after deletion or its privileges were updated. I don't think we need a logic to drop it from cache at the moment

The change I did: we need to make sure descriptors is not null aka contains some valid privileges.

```

### Testing with feature flags
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,7 @@ import { FtrProviderContext } from '../../ftr_provider_context';
export default function ({ loadTestFile }: FtrProviderContext) {
describe('serverless observability UI - feature flags', function () {
// add tests that require feature flags, defined in config.feature_flags.ts
loadTestFile(require.resolve('./role_management'));
loadTestFile(require.resolve('./infra'));
loadTestFile(require.resolve('../common/platform_security/navigation/management_nav_cards.ts'));
loadTestFile(require.resolve('../common/platform_security/roles.ts'));
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,100 @@
/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
* or more contributor license agreements. Licensed under the Elastic License
* 2.0; you may not use this file except in compliance with the Elastic License
* 2.0.
*/

import expect from '@kbn/expect';
import { FtrProviderContext } from '../../../ftr_provider_context';
import { RoleCredentials } from '../../../../shared/services';

export default function ({ getPageObjects, getService }: FtrProviderContext) {
const pageObjects = getPageObjects(['svlCommonPage', 'timePicker', 'common', 'header']);
const samlAuth = getService('samlAuth');
const supertestWithoutAuth = getService('supertestWithoutAuth');
const esArchiver = getService('esArchiver');
const kibanaServer = getService('kibanaServer');
const testSubjects = getService('testSubjects');
let roleAuthc: RoleCredentials;

describe('With custom role', function () {
// skipping on MKI while we are working on a solution
this.tags(['skipMKI']);
before(async () => {
await esArchiver.loadIfNeeded('test/functional/fixtures/es_archiver/logstash_functional');
await kibanaServer.importExport.load('test/functional/fixtures/kbn_archiver/discover');
await kibanaServer.uiSettings.update({
defaultIndex: 'logstash-*',
});
await samlAuth.setCustomRole({
elasticsearch: {
indices: [{ names: ['logstash-*'], privileges: ['read', 'view_index_metadata'] }],
},
kibana: [
{
feature: {
discover: ['read'],
},
spaces: ['*'],
},
],
});
// login with custom role
await pageObjects.svlCommonPage.loginWithCustomRole();
await pageObjects.svlCommonPage.assertUserAvatarExists();
});

after(async () => {
await esArchiver.unload('test/functional/fixtures/es_archiver/logstash_functional');
await kibanaServer.importExport.unload('test/functional/fixtures/kbn_archiver/discover');
await kibanaServer.uiSettings.replace({});
await kibanaServer.savedObjects.cleanStandardList();
if (roleAuthc) {
await samlAuth.invalidateM2mApiKeyWithRoleScope(roleAuthc);
}
// delete custom role
await samlAuth.deleteCustomRole();
});

it('should have limited navigation menu', async () => {
await pageObjects.svlCommonPage.assertUserAvatarExists();
// discover navigation link is present
await testSubjects.existOrFail('~nav-item-id-last-used-logs-viewer');

// all other links in navigation menu are hidden
await testSubjects.missingOrFail('~nav-item-id-dashboards');
await testSubjects.missingOrFail('~nav-item-id-observability-overview:alerts');
await testSubjects.missingOrFail('~nav-item-id-observability-overview:cases');
await testSubjects.missingOrFail('~nav-item-id-slo');
await testSubjects.missingOrFail('~nav-item-id-aiops');
await testSubjects.missingOrFail('~nav-item-id-inventory');
await testSubjects.missingOrFail('~nav-item-id-apm');
await testSubjects.missingOrFail('~nav-item-id-metrics');
await testSubjects.missingOrFail('~nav-item-id-synthetics');

// TODO: 'Add data' and 'Project Settings' should be hidden
// await testSubjects.missingOrFail('~nav-item-id-observabilityOnboarding');
// await testSubjects.missingOrFail('~nav-item-id-project_settings_project_nav');
Comment on lines +76 to +78
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Screenshot 2024-10-16 at 12 01 26

I believe both Add Data and Project Settings should be hidden when role has no access to it.

});

it('should access Discover app', async () => {
await pageObjects.common.navigateToApp('discover');
await pageObjects.timePicker.setDefaultAbsoluteRange();
await pageObjects.header.waitUntilLoadingHasFinished();
expect(await testSubjects.exists('unifiedHistogramChart')).to.be(true);
expect(await testSubjects.exists('discoverQueryHits')).to.be(true);
});

it('should access console with API key', async () => {
roleAuthc = await samlAuth.createM2mApiKeyWithRoleScope('customRole');
const { body } = await supertestWithoutAuth
.get('/api/console/api_server')
.set(roleAuthc.apiKeyHeader)
.set(samlAuth.getInternalRequestHeader())
.set({ 'kbn-xsrf': 'true' })
.expect(200);
expect(body.es).to.be.ok();
});
});
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
* or more contributor license agreements. Licensed under the Elastic License
* 2.0; you may not use this file except in compliance with the Elastic License
* 2.0.
*/

import { FtrProviderContext } from '../../../ftr_provider_context';

export default function ({ loadTestFile }: FtrProviderContext) {
describe('Role Management', function () {
loadTestFile(require.resolve('./custom_role_access'));
});
}
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,8 @@ export default function ({ getPageObjects, getService }: FtrProviderContext) {
if (roleAuthc) {
await samlAuth.invalidateM2mApiKeyWithRoleScope(roleAuthc);
}
// delete custom role
await samlAuth.deleteCustomRole();
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need to delete role, because platform security tests validate security roles UI and roles list.

});

it('should have limited navigation menu', async () => {
Expand Down