Enhancement: added --insecure-tls

[eunames]

Summary

• Short summary of what's included in the PR
• Give special note to breaking changes: List the exact changes or provide links to documentation.

Checklist

For Code changes

• Categorize the PR by setting a good title and adding one of the labels:
  bug, enhancement, documentation, change, breaking, dependency
  as they show up in the changelog
• PR contains the label area:operator
• Link this PR to related issues
• I have not made any changes in the charts/ directory.

Added the oportunity to set a flag --insecure-tls for the restic command.
If you want to set the flag --insecure-tls you should set env SET_INSECURE_TLS_FLAG to true in deployment of k8up operator.

Example:

  template:
    spec:
      containers:
      - args:
        - operator
        env:
        - name: BACKUP_ENABLE_LEADER_ELECTION
          value: "true"
        - name: BACKUP_OPERATOR_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: SET_INSECURE_TLS_FLAG
          value: "true"

fixed:
#792
#882
#881

[Kidswiss]

Hi @eunames

Thank you for the PR!

I feel like adding this as an operator level configuration is not very flexible. With this each and every backup either has it enabled or disabled.

This might be fine for a k8s cluster with only one tenant, however K8up is frequently used in a multi-tenant environment. Setting a security critical configuration globally is not a good idea in such a scenario, as it could compromise the security of the tenants.

So instead, it would be the more flexible approach to add a new flag in the backup CRD and then set SET_INSECURE_TLS_FLAG accordingly on the restic jobs. This way each tenant can configure the setting for each backup individually.

Can you please have a look at my suggestion? From what you already have it shouldn't be too hard to add it to the CRD and pass it to the restic jobs.

[eunames]

Hi
It a more flexible solution i think.
Now customer can set SET_INSECURE_TLS_FLAG in an operator level like was before and/or in a backup card.
So now customer can set flag in the deployment of k8up operator

 template:
     spec:
       containers:
       - args:
         - operator
         env:
         - name: BACKUP_ENABLE_LEADER_ELECTION
           value: "true"
         - name: BACKUP_OPERATOR_NAMESPACE
           valueFrom:
             fieldRef:
               apiVersion: v1
               fieldPath: metadata.namespace
         - name: SET_INSECURE_TLS_FLAG
           value: "true"

Or/and

in the backup card set a flag insecureTLS

apiVersion: k8up.io/v1
kind: Backup
metadata:
  name: backup-true
spec:
  failedJobsHistoryLimit: 2
  successfulJobsHistoryLimit: 2
  backend:
    repoPasswordSecretRef:
    	.....
    insecureTLS: true
    s3:
    	....

A value TRUE in the operator level has priority over a value FALSE in the backup card

But I'm not sure that I've considered all the options when customer can use an insecire connection!!! and testing...... Sorry :(

[Kidswiss]

A value TRUE in the operator level has priority over a value FALSE in the backup card

This feels somewhat like the wrong way around. All other operator level options have less precedence than the options in the backup object.

Also, are you still testing, or is this ready for a re-review from my side?

[eunames]

Ready.
Unfortunate, i can't start buil-in tests (kind's finished with error) and do manual testing at a good level. I think a probability of errors is high.

[Kidswiss]

Ready. Unfortunate, i can't start buil-in tests (kind's finished with error) and do manual testing at a good level. I think a probability of errors is high.

You're right, a few tests are currently failing. Could you take a look at them?