-
Notifications
You must be signed in to change notification settings - Fork 79
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
Harbor opa agent #135
base: main
Are you sure you want to change the base?
Harbor opa agent #135
Changes from 32 commits
3d2a3a2
3066765
6757627
8ed60b6
b3b1361
e8fbb03
4dc472e
2432fa7
1d9526c
22bf648
930f3a6
e99c2ac
816c7b5
287503b
bfcf10e
e7f6842
3ac2c69
b7dceab
803e054
1aa9325
aeb89a5
a2920b4
490a75f
1ab40dc
dd8d47a
13f658f
4e400c2
49dd8a7
67ec26d
7a5648a
b24062a
def0217
b06b565
22b878c
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 |
---|---|---|
@@ -0,0 +1,157 @@ | ||
# Proposal: Integrate Harbor with Open Policy Agent | ||
|
||
Author: Prahalad Deshpande | ||
|
||
## Abstract | ||
This proposal introduces an integration between Harbor and the [Open Policy Agent](https://www.openpolicyagent.org/). This integration will allow users to evaluate and enforce custom policies on images being stored and retrieved from Harbor. Additionally, the integration would also allow a variety of security and compliance enforcement checks to be performed as a part of the build and deploy pipelines by exposing a uniform set of APIs. | ||
The motivation behind this proposal is the Common Vunerability Schema Specification for the Cloud Native Workload. Integrating Harbor with OPA will introduce rich policy evaluation capabilities within Harbor in addition to opening up to other potential integrations with the tools for enforcement of IT GRC compliance in the cloud native ecosystem | ||
|
||
## Background | ||
Harbor currently has support for scanning images for OS vulnerabilities using the [pluggable scanner framework](https://github.com/goharbor/pluggable-scanner-spec). Using the framework, end users can use OS vulnerability scanners of their choice to understand the OS vulnerabilities present within the system. However, reporting capabilities of Harbor with respect to the security and compliance posture of the images persisted within it is very minimal and is restricted to providing a summarized aggregate for the High, Medium and Low vulnerabilities within the images. There are some other crucial limitations such as: | ||
* The scanning for vulnerabilities is scoped to images within a project of which the end user is a member | ||
* There is no mechanism available for the end users to utilize the results of the scan to make further actionable decisions for e.g. quarantining the image or prevent creation of Pod workloads from these images in Kubernetes clusters. | ||
* There is also no mechanism right now to "slice and dice" the results of the vulnerability evaluation. | ||
|
||
The above limitations introduce shortcoming in addressing of critical security use cases of the enterprise security administrator who is concerned about the security and compliance posture of the applications being deployed and the container registry itself (including identification of projects containing the offending images) as opposed to individual project level granularities. | ||
Additionally, from the dev-ops perspective; it is not possible to build a deployment criteria that prevents deploying a service based out of an image not satisfying the acceptance criteria or pre-empt the creation of deployment artifacts (e.g. Helm charts) when the deployments use images that do not satisfy the acceptance criteria. | ||
Additionally, there also exists a critical requirement for the end user to be able to author complex policies that can evaluate the results of an image scan and produce an output that flags the image as matching or failing the acceptance criteria and also share the policies across departments to implement and enforce set of best practices uniformly. | ||
|
||
To address the above requirements and use cases, an integration between Harbor and [Open Policy Agent](https://www.openpolicyagent.org/) is proposed. Open Policy Agent (OPA) is the policy authoring and evaluation framework that is being adopted widely by the Cloud Native Computing Foundation. Refer to [OPA Integrations](https://www.openpolicyagent.org/docs/latest/ecosystem/) to see a set of compelling and interesting integrations. | ||
|
||
##Use Cases | ||
|
||
### Security Admin Persona | ||
* What are the **Critical** vulnerabilities present in my **Harbor registry**? | ||
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. this already exists but we need ability to display these across all projects that user is entitled do, instead of having to dig into each project to view 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. Got it. Some of the use cases mentioned here can be satisfied with the current implementations in harbor too with enhancements to the user interface. I was enlisting the use cases from a completeness perspective with respect to policy integration. 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. Disagree. IMO, OPA integration should focus on policy enforcement, not data querying or reorganization. This can be covered by other tools/services. 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. @steven-zou I agree with your point in principle. The above use case can be satisfied by re-organizing the data within the harbor database to confirm to the schema mentioned in the original document shared related to Cloud Native Common Vunerability Evaluation and Reporting Framework.I will create a separate proposal for that. However, the very nature of OPA is that it allows users to write policies that need not be decision making based. I my understanding is correct, eventually Harbor would also function as a policy store for image compliance policies (@xaleeks please correct my understanding if wrong) and these policies need not be only those that return This type of integration would open up the possibility for the user to run custom analytics and queries against the Harbor OPA data store. @xaleeks please let us know what you think 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. @steven-zou I agree with you that in in principle, the above use case can be achieved using data schema re-organization as was described in the original document shared related to Cloud-Native Common Vulnerability Specification. |
||
* Which images are impacted by **CVE-12345** which has been flagged as business critical? | ||
* Which Helm charts use images with **Critical** vulnerabilities? | ||
* Where can I get access to a summary report on a regular cadence? | ||
* What **Services** out in the field use an image containing **CVE-12345**? | ||
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 don't know if harbor itself can answer that question because we don't track things 'out in the field', this seems like a question for something like sonobuoy that can work in conjunction with Harbor 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 agreed. This is not the functionality of core Harbor. However, Harbor OPA integration would be storing the OPA policy evaluation results and hence could act as the data store that can be used by frameworks like Sonobuoy. 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. Seem concerns with @xaleeks. I don't think Harbor has answers to those questions too. 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. @steven-zou As mentioned in my response above - Harbor need not answer this as it's core functionality. However, the OPA data store in Harbor would be able to answer this query for external tools. @xaleeks please comment on what you think about this particular approach. |
||
* I have a set of enterprise wide "Acceptance for Use" critieria that must be satisified. How can I identify images that satisfy these criteria and those that do not? | ||
* How can I share the best practice checks that I have designed with my enterprise partner organizations so all maintain the same level of compliance? | ||
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. what is this referring to? replicating opa policies to another harbor instance? 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. We can replicate the best practices and compliance checks across the board to maintain a uniform level of compliance across the board. It also allows for centralized policy authoring |
||
* I want to evaluate images against standard IT-GRC policies (PCI, HIPAA) and score images against these policies. | ||
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. how would the scoring be accomplished? 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. Using OPA policies. The user would write custom OPA policies using rego (a policy language used by OPA) where the scoring logic can implemented. The scores can then be retrieved from the Harbor OPA data store. 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. It sounds statistic calculations. Need to depend on OPA? 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. @steven-zou There is a need to depend upon OPA for this. While at the base level, the task involves querying data from the data store and aggregating then using some calculations; these calculations would need to be done in OPA on the fetched data if we want to come up with standard scoring policies that can be shared across the board.
The results in step 3 can then be queried by external tools and services to take further actions/decisions |
||
* I want to apply custom scoring policy on images based on my organization's acceptance criteria. I then want to ensure that images with low score are not permitted to be used when launching any workloads. | ||
|
||
|
||
### Dev Ops Persona | ||
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. is this equivalent to the system admin? 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. Nope. This persona refers to someone or something (like say a Kubernetes Operator) who would be responsible for creating services and pods in production kubernetes or docker swarm clusters from the images stored in Harbor. |
||
|
||
* Do not deploy a service S which uses images containing a **Critical** vulnerability **V** | ||
* Fail the creation of Helm charts if they use an image with **Critical** vulnerabilities. | ||
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. there's no building of helm charts on harbor atm 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. However, as mentioned previously, if Harbor OPA were to store the results of the policy scanning, then the deployment scripts would be able to query this data and decide on the next steps. 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. Does Helm CLI provide such an interface for integration? Or it depends on the user's behavior. 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. Here the thing you mentioned is not preventing pulling from Harbor, right? Do you want to provide a querying service for calling? 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 was referring to the Helm Plug-ins (https://helm.sh/docs/topics/plugins/) which can be written in any language as per the documentation. Users have the ability to write their own plug-ins that will take actions based on the data queried from the Harbor OPA data store. Here is a workflow that can be achieved with Helm:
As has been mentioned in the design below, a reporting API layer would expose the harbor OPA data store to be queried by the external world. |
||
|
||
### Application Developer/Owner Persona | ||
* Pull images having that have a PCI compliance policy evaluation score greater than 8 out of 10 | ||
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 assume 'pull' and 'deploy a service' is the same thing? 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. Actually I was referring to the Harbor functionality where-in we can fetch images from another registry like say Docker. The intent here is to ensure that when images are pulled from Docker, they would be scanned and evaluated for compliance using the Harbor OPA agent prior to the operation being marked as successful/failed. |
||
|
||
### Project Owner Persona | ||
* Quarantine images whose PCI compliance policy evaluation score is less than 8 | ||
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. what does quarantine mean in harbor? We don't have this concept 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, Harbor currently does not have this functionality. What however this implies is that a workflow can be developed where-in Harbor OPA flags non-compliant images and then Harbor either runs a Garbage Collection on them or prevents the use and replication of such flagged images 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. Per my understanding, 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. @steven-zou by the term |
||
* Do not replicate images having vulnerability **CVE-12345** to any destination. | ||
* Do not replicate images with low PCI scores to my production Harbor registry. | ||
|
||
|
||
|
||
|
||
As can be seen from the use cases above; there is a requirement to persist the results of a scan or vulnerability evaluation in a format that supports ad-hoc querying as well as presentable within a report. | ||
|
||
Additionally, there also exists a critical requirement for the end user to be able to author complex policies that can evaluate the results of an image scan and produce an output that flags the image as matching or failing the acceptance criteria and also share the policies across departments to implement and enforce set of best practices uniformly. | ||
|
||
## Proposal | ||
|
||
The next sections describe the user workflows, low level architectures and messaging flow that enable the Harbor - OPA integration | ||
|
||
### Harbor Policy Agent User Workflow | ||
|
||
Keeping adherance the multi-tenancy tenets of Harbor, OPA policies would be scoped at a per-user level and would be availble for use across **all** projects of which the user is a member. This level of scoping will satisfy the following scenarios: | ||
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. scoped means users can author his own policies right? not enforced at the user level, that would be messy 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. Correct. The term scoped has been used to refer to the fact that the user can author and upload/update his/her policies. It is not enforcement at the user level. |
||
* Users can author policies relevant to the projects that they manage or a member of and ensure that images within those projects can evaluated against the policies | ||
* Helps easy migration to a cloud based deployment where-in each user would be a tenant and could own multiple projects against which the policies can be evaluated. | ||
* To satisfy the use case of an uber registry wide or organization specific Security Admin persona, a new user account for the Security Admin can be created and all enterprise wide acceptance policies can be placed under the Security Admin account. Security Admins can then run evaluations against these policies either on demand or inline with a scan or using a periodinc schedule. | ||
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. so are policies created centrally by a new security admin role or specified at the user level mentioned earlier? It might turn into one of those project vs system where project can extend or system level settings as is the case for cve whitelisting 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. Policies can be authored at both levels. The system wide policies are more like the Enterprise wide policies which every image must adhere to, whereas individual projects could have additional policies that the images should comply. A typical example could be that all Photon images used within Acme E-Commerce Corp must have the latest certified build of Photon. Additionally, images lying within the Harbor project owned by the Payment Services team must comply with PCI related checks 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. It's very different from the current harbor design. For applying to multiple projects, it's put at the system level. For a single project, it's put under the specified project. At present Harbor does not support managing resources at the same place for users with different permissions. Actually, I like this management view. But it seems not doable based on current Harbor implementation. 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. @steven-zou The mechanism I am proposing here is the same as about is applied for CVE whitelists as @xaleeks has already mentioned. I also went through the documentation here https://goharbor.io/docs/1.10/administration/vulnerability-scanning/configure-system-whitelist/. |
||
|
||
* **Note Security Admin Persona is not within the scope of this proposal and would need to be treated as a separate proposal** | ||
|
||
|
||
The below sub-sections detail some of the proposed workflows. Instead of providing a UI mockup, the focus is on the segues through which the user will navigate to accomplish actions related to Policy evaluation and reporting | ||
|
||
**Images and icons need to be finalized and are used for illustration purposes only** | ||
|
||
#### Accessing Policy Functionality in Harbor | ||
|
||
The below mockup shows the mechanism of accessing the Policy functionality within harbor | ||
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. this would need system admin access fyi, so project admin would not be able to access these 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. Got it. That was an illustration. However, we can have a mechanism where-in even project admins could be able to author and upload policies. I have not been able to come up with the UX/UI for that at the moment 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. It's inconsistent with the workflow design shown above. All the sections under 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. @steven-zou - I placed it within that panel only for the purpose of illustration. Individual project owners who are not system admins can upload their authored policy bundle as mentioned in the new screenshot that I have provided. |
||
![Harbor Policy Upload Screen](../images/opaintegration/Harbor_Policy_Link.png) | ||
|
||
#### Policy Upload User Workflow | ||
|
||
![Harbor Policy Upload User Workflow](../images/opaintegration/User_Policy_Upload_Diagram.png) | ||
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. so is this where OPAs are injected? 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. Correct. |
||
|
||
#### Policy Evaluation - Policy Centric Workflow | ||
|
||
The below diagram depicts the user workflow to be followed for a policy centric evaluation i.e. the policy is a reference point against which images are evaluated | ||
|
||
![Harbor Policy Evaluation Policy_Centric](../images/opaintegration/User_Policy_Evaluation_Policy_Centric.png) | ||
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 the 'policies' tab should just hold policies, they are executed against in the actual projects, just like vulnerability scanning, ie the configuration of the scanners vs the actual execution of the scans 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, that is how it would be. Policies tab lists the policies and then the user can select the policies that need to be evaluated against images in the projects where they are an admin. 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. As rego policies are pure texts, maybe supporting online editor can also be an option. 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. Sure. That would actually provide for an integrated experience :). But again it could be taken up in a later iteration IMHO, after implementing the core OPA integration pipeline. |
||
|
||
|
||
#### Policy Evaluation - Policy Centric Workflow | ||
|
||
The below diagram depicts the user workflow to be followed for a image centric evaluation i.e. the image is a reference point against which policies are evaluated | ||
|
||
![Harbor Policy Evaluation Image_Centric](../images/opaintegration/User_Policy_Evaluation_Image_Centric.png) | ||
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. got it, this is akin to the vulnerability scanning experience 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. Yep, it is similar to the vulnerability scanning experience. |
||
|
||
#### Policy Evaluation Reporting Workflow | ||
|
||
![Harbor Policy Evaluation Reporting Workflow](../images/opaintegration/User_Policy_Evaluation_Reports.png) | ||
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. what does the report look like for a single policy, is this aggregated summary of all historical evaluations against this policy, across all projects for this particular user? what if I'm logged in as the security admin 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 have not yet come up with the UI representation of the report. But in terms of content it would be what you said. I was envisioning a simple tabular list enumerating the image, the corresponding project and a link to the latest evaluation report. Do we need historical results? I will update the content to be a more specific once we complete this initial discussion 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. It seems you're using OPA policy to support some new functions. Before checking this, I was thinking we can use OPA to do compliance checking in the middleware layer by the harbor system (not by users) and replace the current checking policies that are implemented with native code. @xaleeks What do you think? |
||
|
||
|
||
The next sections detail the low level architecture and component view and interaction diagrams for the Harbor Policy Agent | ||
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. please help review @steven-zou @reasonerjt 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. Can we make the OPA itself a configurable service? That means I can leverage my existing OPA to do the work. The user just needs to specify an OPA endpoint in harbor side. I don't think the policy agent needs to listen to the job service webhook, it can directly listen to the harbor webhook which includes the ScanComplete event. The architecture is not too clear and may need to be refactored. Actually, the most important thing is before reviewing the implementation design details we need to reach an agreement on the points in the previous sections, especially the personas/user stories. I'm thinking whether we need to expand the OPA to be a policy engine as well as a metric engine or not. And whether we should provide entries for users to directly run policy evaluations and check results. We can continue the offline discussions. 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. @steven-zou Yes, the OPA instance being used could be something that already exists in the user environment and Harbor can be made to talk to that. In fact, all the PoCs that have been demonstrated until now, have been done using this assumption. I also think that this will result in a more cleaner integration; the OPA instance could be upgraded without impacting Harbor thereby allowing the user to use the latest and greatest features. Additionally, it also absolves Harbor from managing the configuration of OPA. |
||
|
||
### Harbor Policy Agent Component View | ||
|
||
The **Harbor Policy Agent** provides policy evaluation and reporting capabilities within the Harbor ecosystem. A component view of the policy agent is shown below | ||
|
||
![Harbor Policy Agent Component View](../images/opaintegration/Harbor_Policy_Agent.png) | ||
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. please review this architecture @steven-zou @reasonerjt |
||
|
||
The core components of the policy evaluation and reporting layer are | ||
* Policy Agent | ||
* PostgresSQL DB | ||
* Elasticsearch | ||
|
||
#### Policy Agent | ||
The **Policy Agent** contains all the required components for processing OPA policies, evaluating them and then persisting the results of the evaluation to the Postgres DB and Elasticsearch store. Each layer within the **Policy Agent** performs a specific responsibility | ||
* Vulnerability Data Fetch layer - responsible for loading vulnerability an scan data from a set of data stores. The data stores could be based out of a File system or a Database. | ||
* Policy layer - responsible for Policy storage, retrieval and evaluation using th OPA framework. The layer has been further detailed in sections below. | ||
* Storage Layer - responsible for providing the required storage abstractions to various data stores for the policy evaluation results and optionally any additional data. | ||
* Reporting layer - responsible for exposing a set of REST APIs, for querying policy and evaluation data and metrics. | ||
|
||
#### PostgresSQL DB | ||
The PostgresSQL DB will store the results of the policy evaluation process in a normalized form that allows for ad-hoc query of the data. | ||
|
||
#### ElasticSearch | ||
The Elasticsearch data store will store the results of the policy evaluation indexed by the text contents so that a Full Text Search capability is available on the policy data and the policy evaluation results. | ||
|
||
### Harbor Policy Agent Low Level Design | ||
|
||
The low level (interface and struct level) components of the Policy Agent are specified in the below diagram | ||
|
||
![Harbor Policy Agent Low Level Component Diagram](../images/opaintegration/Harbor_Policy_Agent_Detailed_View.png) | ||
|
||
### Harbor Policy Agent Policy Upload Workflow | ||
|
||
The below sequence diagram depicts the interactions between the various components of the **Harbor Policy Agent** during the Policy upload process | ||
|
||
![Harbor Policy Agent Policy Upload Workflow](../images/opaintegration/Harbor_Policy_Workflow_PolicyUpload.png) | ||
|
||
### Harbor Policy Agent Policy Evaluation Workflow | ||
|
||
Harbor Policy Evaluation can be triggered in any of the below three forms | ||
* Inline with an image scan - Policy evaluation happens immediately after an image scan completes | ||
* On demand - Policy evaluation is triggered by the user by specifying a policy Id and an image id for the purposes of the scan | ||
* Scheduled - Policy evaluation can be scheduled to trigger off exactly once or at a periodic interval. | ||
|
||
The below sequence diagram depicts the interactions between the various components of the **Harbor Policy Agent** during the Policy evaluation process. It also depicts how Harbor interacts with the Policy Agent using the Policy HTTP Endpoint to trigger a policy evaluation. | ||
|
||
![Harbor Policy Agent Policy Evaluation Workflow](../images/opaintegration/Harbor_Policy_Evaluation_Workflow.png) | ||
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. where exactly does the agent reside? 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. As mentioned that in the low level component diagram within the architecture, the Agent would be residing on a separate container image within the Harbor network. |
||
|
||
##Misc Considerations | ||
|
||
### Multi-tenancy | ||
|
||
The proposed solution | ||
|
||
### Deployment | ||
|
||
The **Harbor Policy Agent** would be deployed as a service within a container alongside other services that make up the Harbor installation. |
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.
I think this is the real requirement of this feature.