Support using a different s3 bucket through plugin setting

[mickmister]

Summary

This PR makes it so the admin can configure the plugin to store the Legal Hold artifacts in a different S3 Bucket than the one that's currently being used by the Mattermost server. The following fields are filled out by the UI, which is a subset of model.FileSettings. The backend of the plugin uses unmarshals this as a model.FileSettings struct and uses it as such.

type FileSettings = {
    DriverName: string;
    AmazonS3RequestTimeoutMilliseconds: number;
    AmazonS3Bucket: string;
    AmazonS3PathPrefix: string;
    AmazonS3Region: string;
    AmazonS3Endpoint: string;
    AmazonS3AccessKeyId: string;
    AmazonS3SecretAccessKey: string;
    AmazonS3SSL: boolean;
    AmazonS3SSE: boolean;
};

Ticket Link

Fixex #12

[wiggin77]

@mickmister A couple of questions:

1. Is it enough to just have a different bucket name, versus duplicate all the S3 settings? For example, I could see a use case where the credentials are different.

2. He this been tested to ensure the custom bucket gets created and stuff actually gets written there?

[mickmister]

Is it enough to just have a different bucket name, versus duplicate all the S3 settings? For example, I could see a use case where the credentials are different.

@wiggin77 I was thinking it may best to keep it simple now, though now I'm thinking we should lean on the side of data access/isolation, which would involve setting different credentials etc. as you mentioned. I'm planning to add the following plugin settings to uniquely identify the bucket, along with unit tests to cover usage:

• Enable custom S3 bucket - boolean
• S3 bucket name
• S3 path (optional)
• S3 region
• Access key id
• Access key secret

Here are the values that the plugin currently pulls from the MM config:

mattermost-plugin-legal-hold/server/plugin.go

Lines 212 to 225 in 568f22b

	return filestore.FileBackendSettings{
	DriverName: *fileSettings.DriverName,
	AmazonS3AccessKeyId: *fileSettings.AmazonS3AccessKeyId,
	AmazonS3SecretAccessKey: *fileSettings.AmazonS3SecretAccessKey,
	AmazonS3Bucket: amazonS3Bucket,
	AmazonS3PathPrefix: amazonS3PathPrefix,
	AmazonS3Region: amazonS3Region,
	AmazonS3Endpoint: *fileSettings.AmazonS3Endpoint,
	AmazonS3SSL: fileSettings.AmazonS3SSL != nil && *fileSettings.AmazonS3SSL,
	AmazonS3SignV2: fileSettings.AmazonS3SignV2 != nil && *fileSettings.AmazonS3SignV2,
	AmazonS3SSE: fileSettings.AmazonS3SSE != nil && *fileSettings.AmazonS3SSE && enableComplianceFeature,
	AmazonS3Trace: fileSettings.AmazonS3Trace != nil && *fileSettings.AmazonS3Trace,
	AmazonS3RequestTimeoutMilliseconds: *fileSettings.AmazonS3RequestTimeoutMilliseconds,
	SkipVerify: skipVerify,

---

Has this been tested to ensure the custom bucket gets created and stuff actually gets written there?

Yes the legal holds are correctly written to the provided S3 bucket. I've tested with MINIO and will test with an S3 bucket as well

---

I've also added a "connection test" on plugin start up and config change that will error out if the connection fails

[wiggin77]

Here are the values that the plugin currently pulls from the MM config

I think it should be a complete copy of the code the handles the MMserver S3 config. Re-use the structs, copy the system console UI.

[mickmister]

@wiggin77 Sure sounds good to me 👍

[mickmister]

The "plugin settings" page now functions like the "file storage" page with the s3 bucket configuration

legal-hold-system-console.mov

[mickmister]

I put this comment here since right now the UI will be given the stored access secret on page load. Though there is no chance to encrypt/decrypt the config value in the case of saving config values in the system console. Not sure how to proceed with hiding the secret even though it's in plaintext in the server config, and is exposed to the client directly.

[wiggin77]

How is it done in the main mmserver S3 config?

[mickmister]

@wiggin77 The server's config is sanitized before being returned the client, which in this case includes censoring the main product's AWS secret key. But this sanitization step is not available for plugin settings, so they are always delivered as plaintext.

[mickmister]

Created a ticket to address this #54

[wiggin77]

@cwarnermm This PR will require an addition to the Legal Hold plugin docs.

[fmartingr]

Good addition.

My only nit/feature request after checking this locally (not for this PR, more like a wishlist): How difficult could it be to visually group the S3 settings and only show the configuration ones if the custom S3 bucket is enabled?

[mickmister]

How difficult could it be to visually group the S3 settings and only show the configuration ones if the custom S3 bucket is enabled?

@fmartingr I actually did it that way first but changed it to match the way the primary s3 bucket is configured in the system console. Maybe we could have a more intentional way to do this, like a "show/hide settings" button. So the admin could have them hidden even though a custom bucket is configured

[wiggin77]

LGTM 👍