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

Transit: Key Trim #5388

Merged
merged 14 commits into from
Oct 17, 2018
Merged

Transit: Key Trim #5388

merged 14 commits into from
Oct 17, 2018

Conversation

vishalnayak
Copy link
Member

@vishalnayak vishalnayak commented Sep 24, 2018

No description provided.

@vishalnayak vishalnayak added this to the 0.11.2 milestone Sep 24, 2018
originalExportable := p.Exportable
originalAllowPlaintextBackup := p.AllowPlaintextBackup

defer func() {
Copy link
Contributor

@kalafut kalafut Sep 25, 2018

Choose a reason for hiding this comment

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

I guess the intent is that p.Persist in the return restores the old values. Does this defer approach work? Won't the updates to p take place after the Persist call runs? Or did you intend to call Persist in this function? Maybe one of the test case demonstrates this but it wasn't obvious which one.

Copy link
Member Author

Choose a reason for hiding this comment

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

The policy is responded from the cache. The pointer to the policy is being modified in this function. Even if this function errors out, the policy in the cache gets modified accidentally. This is even before the p.Persist is being called. p.Persist however is already doing the right thing. So, this function is only trying to restore values in policy that it is touching.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, didn't notice that p is pointing into the cache. Makes sense then.

@chrishoffman chrishoffman modified the milestones: 0.11.2, next-release Sep 27, 2018
@chrishoffman chrishoffman modified the milestones: next-release, 0.12 Oct 9, 2018
Copy link
Member

@jefferai jefferai left a comment

Choose a reason for hiding this comment

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

I think this needs to be rethought a bit. It doesn't make sense to me to put a trimmed version in config, because the UX feels pretty weird, like, set this config flag which passively takes action, and then the config flag sticks around but doesn't really have meaning anymore.

I think the right approach is likely to create a trim path, maybe keys/<name>/trim that performs the trim in real time, and that a property is added to the key policy indicating the last trimmed version or min available version or so so that logic for archiving and such can know when to stop.

@vishalnayak
Copy link
Member Author

@jefferai The functionality is moved to its own endpoint now.

return logical.ErrorResponse("minimum version cannot be negative"), nil
case p.MinVersion == 0:
return logical.ErrorResponse("minimum version should be positive"), nil
case p.MinVersion < p.MinVersion:
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this will ever be true

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, right. This was a refactoring issue. Fixed.

}
}()

p.MinVersion = minVersionRaw.(int)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not set this after all the validation logic below? We could avoid the defer above if we do it that way and call Persist outside of the return function. e.g.

originalMinVersion := p.MinVersion
p.MinVersion = minVersionRaw.(int)
if err := p.Persist(ctx, req.Storage); err != nil {
    p.MinVersion = originalMinVersion
    return nil, err
}
return nil, nil

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

@@ -206,6 +206,7 @@ func (b *backend) pathPolicyRead(ctx context.Context, req *logical.Request, d *f
"type": p.Type.String(),
"derived": p.Derived,
"deletion_allowed": p.DeletionAllowed,
"min_version": p.MinVersion,
Copy link
Member

Choose a reason for hiding this comment

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

I don't really like the name, I think it's confusing next to min_decryption_version and min_encryption_version. Slightly better might be min_available_version, although that mostly has the same problem. Possibly first_available_version?

Copy link
Member Author

Choose a reason for hiding this comment

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

min_available_version is better I suppose. first_available_version is slightly confusing.

@@ -326,6 +326,13 @@ type Policy struct {
// a max.
ArchiveVersion int `json:"archive_version"`

// ArchiveMinVersion is the minimum version of the key in the archive.
ArchiveMinVersion int `json:"archive_min_version"`
Copy link
Member

Choose a reason for hiding this comment

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

This seems redundant. Archiving is simply a factor of the min decryption version. So if the min decryption version is the same as the min version (or, first available version), nothing is in the archive; otherwise, the first version in the archive is the same as min version.

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 don't feel that this is redundant (unless I am failing to see your point). The policy that invokes handleArchiving might already have MinAvailableVersion modified. So, we can't rely on that. We want the last used MinAvailableVersion, which is held by ArchiveMinVersion.

Copy link
Member

Choose a reason for hiding this comment

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

Gotcha, sounds good then.

@jefferai
Copy link
Member

Looking good! Will defer to Brian or Chris for final 👍

Copy link
Contributor

@briankassouf briankassouf left a comment

Choose a reason for hiding this comment

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

LGTM!

@vishalnayak vishalnayak merged commit 10dc743 into master Oct 17, 2018
@vishalnayak vishalnayak deleted the transit-key-trim branch October 17, 2018 16:05
@jefferai jefferai modified the milestones: 0.12, 0.11.4 Oct 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants