Initial movement of the day2 code

[lubronzhan]

Depends on #812

Major changes:

• apis. Added two types, harborserverconfiguration and pullsecretbinding.
• assets. The swagger spec for harbor v1 and v2
• config/default/webhook_namespaceselector_patch.yaml. It will skip mutating image path if namespace is labeled with harbor-day2-webhook-configuration=disabled
• controllers
  • harborserverconfiguration
  • pullsecretbinding
  • namespace
• pkg
  • setup. Set up harborserverconfiguration and mutate-image-path webhook separately.
  • http. An insecure https client that used to talk to Harbor server
  • Registry . Used to encode harbor credentials for http request use
  • rest. Client wrapper for v1 and v2 server.
  • rule. Rule type used for image rewrite.
  • sdk. Swagger generated client code.
  • utils
    • consts. Storing all annotation of harbor day2 operator
    • sdk_client. Wrapper client for
• webhooks
  • harborserverconfiguration
  • pod. Has image path mutator.

Feature:

Image rewrite:

Image rewrite will rewrite the original image paths to the specified Harbor projects by following the pre-defined rewriting rules via Kubernetes admission control webhook.

A cluster scoped Kubernetes CR named HarborServerConfiguration is designed to keep the Harbor server access info by providing the access
host and access key & secret (key and secret should be wrapped into a kubernetes secret) for future referring.

Rewriting rule is a k-v pair to specify images from which repo should be redirected to which harbor project:

e.g.:

`"docker.io": "harborproject1"` or `"*": "harborproejct2"`

Here we should pay attention is the key "*" means images from any repo are redirected to harbor project "harborproejct2".

Rewriting rules will be defined as a rule list like:

rules:
  - docker.io:harborproject1
  - *:harborproejct2
  - quay.io:harborproejct3

Definition location:

The rewriting rules can be defined into two places, one is in the HSC spec and another is in a configMap.

Rules in HSC spec are for the whole cluster scope. The rules will be applied to the namespaces selected by the namespace selector of HSC.

The rules defined in the configMap are only visible to the namespace where the configMap is living. Use annotation of namespace goharbor.io/image-rewrite(rename to goharbor.io/rewriting-rules) to link the rule configMap.

The priority:

Rules in configMap > rules in HSC referenced by ConfigMap > default HSC > "*" rule

For example. images from docker.io will be rewritten to 'harborproject1' and images from quay.io will be rewritten to 'harborproejct3'. The images from gcr.io or ghcr.io will both be rewritten to 'harborproejct2' by following the "*" rule.

Assumptions:

Only 1 HSC as default. (ctrl has to make sure this constraint)
Default HSC is appliable for all namespaces as the default behavior (except its namespace selector is configured).
HSC can have a namespace selector to specify its influencing scope.
Namespace selector is optional. The empty selector means adapting all.

Namespace admin can create a configMap to customize image rewriting for the specified namespace:

Content of configMap

hsc: myHscName ## if this ns missing the selector of the specfying HSC, log warnning and no action.
rewriting: on ## or off
rules: -|
  - docker.io:harborproject1-1
  - *:harborproejct2-1
  - quay.io:harborproejct3-1

Add annotation goharbor.io/rewriting-rules=configMapName to the namespace to enable the rewriting.

Merging rules: rules defined in configMap has higher priority if conflicts happened.

Project mapping and secret injection:

When doing project mapping and secret injection, an annotation goharbor.io/project MUST be added to the specified namespace ( if goharbor.io/project is not set, that means the mapping/injection function is not enabled).

A CR PullSecretBinding is created to keep the relationship between Kubernetes resources and Harbor resources.

• the mapping project is recorded in annotation annotation:goharbor.io/project of the CR PullSecretBinding.

• the linked robot account is recorded in annotation annotation:goharbor.io/robot of the CR PullSecretBinding.

• make sure the linked robot account is wrapped as a Kubernetes secret and bind with the service account that is
  specified in the annotation annotation:goharbor.io/service-account of the namespace.

• If goharbor.io/project=*, then check whether annotation goharbor.io/secret-issuer (it should be renamed to goharbor.io/harbor) which is pointing to an HSC (It should be provided by the cluster-admin) is set or not. If it is not set, then back off to the default HSC. If there is no default HSC, then an error should be raised. When HSC is ready, create a Harbor project with the same name of the namespace in that HSC and also create a robot account in the newly created Harbor project. After the robot account is created, the identity of the created robot account should be recorded into the annotation goharbro.io/robot (it should be renamed to goharbor.io/robot-account).

• If goharbor.io/project=, then the annotation goharbor.io/robot=<robot_ID> MUST also be set to a valid robot account that is living in the project representing by the annotation goharbor.io/project. The controller has to make sure the robot specified in the annotation can be used to access the project (by accessing API with that robot account).

  • If the specified project name does not exist or the robot account provided does not mismatch, then log the error (should not return an error in the reconcile process)

Then a PSB can be created to track the relationship and bind pull secret to the service account:

• wrap the robot account as a secret
• bind the secret to the service account which is specified by the annotation goharbor.io/service-account (this is optional, if it is not set, then use the default service account under the namespace)

[bitsf]

for compile issue

diff --git a/pkg/rest/v2/client.go b/pkg/rest/v2/client.go
index 2cbff160..30c6460d 100644
--- a/pkg/rest/v2/client.go
+++ b/pkg/rest/v2/client.go
@@ -103,7 +103,7 @@ func (c *Client) EnsureProject(name string) (int64, error) {
 			},
 		})
 
-	cp, err := c.harborClient.Client.Project.CreateProject(cparams, c.harborClient.Auth)
+	cp, err := c.harborClient.Client.Project.CreateProject(c.context, cparams)
 	if err != nil {
 		return -1, fmt.Errorf("ensure project error: %w", err)
 	}
@@ -125,7 +125,7 @@ func (c *Client) GetProject(name string) (*v2models.Project, error) {
 		WithTimeout(c.timeout).
 		WithName(&name)
 
-	res, err := c.harborClient.Client.Project.ListProjects(params, c.harborClient.Auth)
+	res, err := c.harborClient.Client.Project.ListProjects(c.context, params)
 	if err != nil {
 		return nil, fmt.Errorf("get project error: %w", err)
 	}
@@ -147,16 +147,10 @@ func (c *Client) DeleteProject(name string) error {
 		return errors.New("nil harbor client")
 	}
 
-	// Get ID first
-	p, err := c.GetProject(name)
-	if err != nil {
-		return fmt.Errorf("delete project error: %w", err)
-	}
-
 	params := project.NewDeleteProjectParamsWithContext(c.context).
 		WithTimeout(c.timeout).
-		WithProjectID((int64)(p.ProjectID))
-	if _, err = c.harborClient.Client.Project.DeleteProject(params, c.harborClient.Auth); err != nil {
+		WithProjectNameOrID(name)
+	if _, err := c.harborClient.Client.Project.DeleteProject(c.context, params); err != nil {
 		return err
 	}
 

[bitsf]

@lubronzhan we also can't install harbor using chart with this PR locally.
The problem seems because webhook "mimg.kb.io" is not started correctly, which make redis, postgres also can't created, and also harbor pods can't started.
one possible reason maybe failurePolicy in charts/harbor-operator/templates/mutatingwebhookconfiguration.yaml

[cndoit18]

Using NotIn may cause kube-system to be included

[cndoit18]

Suggested change

	kubectl label ns default harbor-day2-webhook-configuration=disabled
	kubectl label ns ${operatorNamespace} harbor-day2-webhook-configuration=disabled

[cndoit18]

The patch about namespace was not added

[steven-zou]

approved

[steven-zou]

@lubronzhan

The link now can be removed.

[steven-zou]

Filename should also be renamed.