@@ -175,41 +175,60 @@ secret to a ServiceAccount, see [Add image pull secret to service account](https
175175
176176# ## Certificate secret reference
177177
178- ` .spec.certSecretRef` is an optional field to specify a name reference to a
179- Secret in the same namespace as the ImageRepository containing TLS certificate
180- data. This is for two separate purposes :
181- - to provide a client certificate and private key, if you use a certificate to authenticate with the image registry; and,
182- - to provide a CA certificate, if the registry uses a self-signed certificate
178+ ` .spec.certSecretRef.name` is an optional field to specify a secret containing
179+ TLS certificate data. The secret can contain the following keys :
183180
184- These will often go together in case of self-hosted image registry. All the
185- files in the secret are expected to be [PEM-encoded][pem-encoding]. This is an
186- ASCII format for certificates and keys; `openssl` and such tools typically
187- provide an option for PEM output.
181+ * `tls.crt` and `tls.key`, to specify the client certificate and private key used
182+ for TLS client authentication. These must be used in conjunction, i.e.
183+ specifying one without the other will lead to an error.
184+ * `ca.crt`, to specify the CA certificate used to verify the server, which is
185+ required if the server is using a self-signed certificate.
188186
189- Assuming that a certificate file and private key are in files `client.crt` and
190- `client.key` respectively, a secret can be created with `kubectl` :
187+ If the server is using a self-signed certificate and has TLS client
188+ authentication enabled, all three values are required.
189+
190+ The Secret should be of type `Opaque` or `kubernetes.io/tls`. All the files in
191+ the Secret are expected to be [PEM-encoded][pem-encoding]. Assuming you have
192+ three files; `client.key`, `client.crt` and `ca.crt` for the client private key,
193+ client certificate and the CA certificate respectively, you can generate the
194+ required Secret using the `flux create secret tls` command :
191195
192196` ` ` sh
193- kubectl create secret generic tls-certs \
194- --from-file=certFile=client.crt \
195- --from-file=keyFile=client.key
197+ flux create secret tls --tls-key-file=client.key --tls-crt-file=client.crt --ca-crt-file=ca.crt
196198` ` `
197199
198- An [encrypted secret](sops-guide) can also be used; the important bit is that
199- the data keys in the secret are `certFile` and `keyFile`.
200-
201- In case of a CA certificate for the client to use, the data key for it is
202- ` caFile` . Adapting the previous example, if the certificate is in the file
203- ` ca.crt` , and the client certificate and key are as before, the whole command
204- would be :
200+ Example usage :
205201
206- ` ` ` sh
207- kubectl create secret generic tls-certs \
208- --from-file=certFile=client.crt \
209- --from-file=keyFile=client.key \
210- --from-file=caFile=ca.crt
202+ ` ` ` yaml
203+ ---
204+ apiVersion: image.toolkit.fluxcd.io/v1beta2
205+ kind: ImageRepository
206+ metadata:
207+ name: example
208+ namespace: default
209+ spec:
210+ interval: 5m0s
211+ url: example.com
212+ certSecretRef:
213+ name: example-tls
214+ ---
215+ apiVersion: v1
216+ kind: Secret
217+ metadata:
218+ name: example-tls
219+ namespace: default
220+ type: kubernetes.io/tls # or Opaque
221+ data:
222+ tls.crt: <BASE64>
223+ tls.key: <BASE64>
224+ # NOTE: Can be supplied without the above values
225+ ca.crt: <BASE64>
211226` ` `
212227
228+ **Warning:** Support for the `caFile`, `certFile` and `keyFile` keys have been
229+ deprecated. If you have any Secrets using these keys and specified in an
230+ ImageRepository, the controller will log a deprecation warning.
231+
213232# ## Suspend
214233
215234` .spec.suspend` is an optional field to suspend the reconciliation of an
0 commit comments