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

Authorization - fully implemented registry part #133

Merged
merged 1 commit into from
May 25, 2020

Conversation

tomeresk
Copy link
Contributor

@tomeresk tomeresk commented Apr 30, 2020

This includes:

  • Create/update policy resource
  • Attachments support for policy resource (with support for writing the attachment to both s3 and fs repositories)
  • Opa policy type implementation, including compiling rego code to wasm and adding that to the policy as an attachment

@tomeresk tomeresk requested review from AvivRubys, Yshayy and a team April 30, 2020 10:06
@@ -26,12 +28,30 @@ export class FileSystemResourceRepository implements ResourceRepository {
await fs.writeFile(this.pathToFile, JSON.stringify(rg));
}

async writePolicy(filename: string, compiledRego: Buffer): Promise<void> {
Copy link
Contributor

@Yshayy Yshayy Apr 30, 2020

Choose a reason for hiding this comment

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

I think that compileRego adds a bit of dependency here to opa and it's too specific, maybe it should abstract as a regular resource and add attachment support? (maybe with path conventions, or getAttachment or something)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree about compiledRego, it was an oversight on my part, I will rename it to something more generic.

Regarding the policy, it is already a regular resource that is saved in the resources file as part of the resource group. This function only writes the attachment (compiled rego in the case of opa) and is generic, so it can work as attachment for other types as well (poor variable naming aside).
After explaining it now I realize the function name itself (writePolicy) is also bad since it doesn't write the policy itself (which is written with the regular update function) but only the attachment. I will rename the function itself as well.

Do you still think other changes are required here other than renaming the compiledRego variable to something like content and the writePolicy function to something like writePolicyAttachment?

As a note, the attachment itself is stored with a name convention based on the metadata of namespace and name, there is no explicit link to it in the policy resource

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Yshayy This is addressed in commit 738408c

@tomeresk tomeresk force-pushed the authorization-registry branch 2 times, most recently from 700c2bc to 3f561e3 Compare May 5, 2020 11:50
@@ -144,8 +222,36 @@ async function fetchAndValidate(updates: Partial<ResourceGroup>): Promise<Resour
return newRg;
}

type tempLocalPolicyAttachment = {metadata: ResourceMetadataInput; path: string; type: PolicyType};
Copy link
Contributor

Choose a reason for hiding this comment

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

This being camelCased is driving me insane I keep thinking it's a variable

Copy link
Contributor Author

@tomeresk tomeresk May 24, 2020

Choose a reason for hiding this comment

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

I can make the change, the standard for type naming is Pascal case?

This includes:
Create/update policy resource
Attachments support for policy resource (with support for writing the attachment to both s3 and fs repositories)
Opa policy type implementation, including compiling rego code to wasm and adding that to the policy as an attachment
@tomeresk tomeresk merged commit 5bde6c9 into authorization May 25, 2020
@tomeresk tomeresk deleted the authorization-registry branch May 25, 2020 09:56
tomeresk added a commit that referenced this pull request May 25, 2020
This includes:
Create/update policy resource
Attachments support for policy resource (with support for writing the attachment to both s3 and fs repositories)
Opa policy type implementation, including compiling rego code to wasm and adding that to the policy as an attachment
AleF83 added a commit that referenced this pull request Jul 2, 2020
* Authorization - fully implemented registry part (#133)

This includes:
Create/update policy resource
Attachments support for policy resource (with support for writing the attachment to both s3 and fs repositories)
Opa policy type implementation, including compiling rego code to wasm and adding that to the policy as an attachment

* Authorization gateway - basic features (#138)

implemented full flow with basic features
Implement local policy attachment caching for all resource repositories

* Add policy definitions and attachments to request context, change pol… (#141)

* Add policy definitions and attachments to request context, change policy executor to use them from context instead of directly from repo

* PR comments

* allow jwt in param injection (policy authorization can use it through args) (#144)

* Support for policy query (#143)

* Policy directive - accept only a single policy (#146)

* change policy directive to accept only a single policy

* Refactored PolicyExecutor API to only expose static methods

Co-authored-by: Tomer Eskenazi <tomeresk@gmail.com>
AleF83 pushed a commit that referenced this pull request Jul 2, 2020
This includes:
Create/update policy resource
Attachments support for policy resource (with support for writing the attachment to both s3 and fs repositories)
Opa policy type implementation, including compiling rego code to wasm and adding that to the policy as an attachment
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.

3 participants