Skip to content

Commit 5ee2327

Browse files
haarchrihaarchri
committed
feat(cas): split doc for crossplane and providers, adding providers documentation
Signed-off-by: Christopher Haar <[email protected]>
1 parent 04feb2a commit 5ee2327

File tree

1 file changed

+133
-25
lines changed

1 file changed

+133
-25
lines changed

‎content/v1.18/guides/self-signed-ca-certs.md‎

Lines changed: 133 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -1,49 +1,157 @@
1-
---
1+
---
22
title: Self-Signed CA Certs
3-
weight: 270
4-
---
3+
weight: 270
4+
---
55

6-
> Using self-signed certificates isn't advised in production, it's
7-
recommended to only use self-signed certificates for testing.
6+
# Crossplane
7+
> Using self-signed certificates isn't advised in production, it's recommended
8+
to only use self-signed certificates for testing.
89

9-
When Crossplane loads Configuration and Provider Packages from private
10-
registries, it must be configured to trust the CA and Intermediate certs.
10+
When Crossplane loads Configuration and Provider Packages from private
11+
registries, it must be configured to trust the CA and Intermediate certs.
1112

12-
Crossplane needs to be installed via the Helm chart with the
13-
`registryCaBundleConfig.name` and `registryCaBundleConfig.key` parameters
13+
Crossplane needs to be installed via the Helm chart with the
14+
`registryCaBundleConfig.name` and `registryCaBundleConfig.key` parameters
1415
defined. See [Install Crossplane]({{<ref "../../master/software/install" >}}).
1516

1617
## Configure
1718

18-
1. Create a CA Bundle (A file containing your Root and Intermediate
19-
certificates in a specific order). This can be done with any text editor or
20-
from the command line, so long as the resulting file contains all required crt
21-
files in the proper order. In many cases, this will be either a single
22-
self-signed Root CA crt file, or an Intermediate crt and Root crt file. The
23-
order of the crt files should be from lowest to highest in signing order.
24-
For example, if you have a chain of two certificates below your Root
25-
certificate, you place the bottom level Intermediate cert at the beginning of
26-
the file, then the Intermediate cert that singed that cert, then the Root cert
27-
that signed that cert.
19+
1. Create a CA Bundle (A file containing your Root and Intermediate certificates
20+
in a specific order). This can be done with any text editor or from the command
21+
line, so long as the resulting file contains all required crt files in the
22+
proper order. In many cases, this will be either a single self-signed Root CA
23+
crt file, or an Intermediate crt and Root crt file. The order of the crt files
24+
should be from lowest to highest in signing order. For example, if you have a
25+
chain of two certificates below your Root certificate, you place the bottom
26+
level Intermediate cert at the beginning of the file, then the Intermediate cert
27+
that singed that cert, then the Root cert that signed that cert.
2828

2929
2. Save the files as `[yourdomain].ca-bundle`.
3030

3131
3. Create a Kubernetes ConfigMap in your Crossplane system namespace:
3232

33-
```
33+
```bash
3434
kubectl -n [Crossplane system namespace] create cm ca-bundle-config \
3535
--from-file=ca-bundle=./[yourdomain].ca-bundle
3636
```
3737

38-
4. Set the `registryCaBundleConfig.name` Helm chart parameter to
39-
`ca-bundle-config` and the `registryCaBundleConfig.key` parameter to
38+
4. Set the `registryCaBundleConfig.name` Helm chart parameter to
39+
`ca-bundle-config` and the `registryCaBundleConfig.key` parameter to
4040
`ca-bundle`.
4141

42-
> Providing Helm with parameter values is covered in the Helm docs,
43-
[Helm install](https://helm.sh/docs/helm/helm_install/). An example block
42+
> Providing Helm with parameter values is covered in the Helm docs,
43+
[Helm install](https://helm.sh/docs/helm/helm_install/). An example block
4444
in an `override.yaml` file would look like this:
45-
```
45+
```yaml
4646
registryCaBundleConfig:
4747
name: ca-bundle-config
4848
key: ca-bundle
4949
```
50+
51+
# Providers
52+
53+
When operating behind a corporate firewall with injected CAs for every endpoint,
54+
you can use your own managed CA for providers. This guide explains how to
55+
achieve this by creating a Kubernetes ConfigMap to mount a custom certificate
56+
bundle.
57+
58+
## Configure
59+
60+
1. Create a ConfigMap for the Certificate Bundle. To use an internal CA
61+
certificate file instead of the default one in the provider container, create
62+
a Kubernetes ConfigMap from the certificate bundle file.
63+
64+
Run the following command to create the ConfigMap:
65+
66+
```bash
67+
kubectl create configmap -n upbound-system cert-bundle --from-file=ca-certificates.crt=/tmp/ca-certificates.crt
68+
```
69+
70+
2. Create a `DeploymentRuntimeConfig` that allows customization of a provider
71+
installation.
72+
73+
```yaml
74+
apiVersion: pkg.crossplane.io/v1beta1
75+
kind: DeploymentRuntimeConfig
76+
metadata:
77+
name: cert-bundle
78+
spec:
79+
deploymentTemplate:
80+
spec:
81+
selector: {}
82+
strategy: {}
83+
template:
84+
spec:
85+
containers:
86+
- name: package-runtime
87+
resources: {}
88+
volumeMounts:
89+
- mountPath: /etc/ssl/certs
90+
name: cert-bundle
91+
volumes:
92+
- configMap:
93+
name: cert-bundle
94+
name: cert-bundle
95+
```
96+
97+
3. Install a Provider and ensure the `runtimeConfigRef` points to the
98+
`DeploymentRuntimeConfig` created in the previous step.
99+
100+
```yaml
101+
apiVersion: pkg.crossplane.io/v1
102+
kind: Provider
103+
metadata:
104+
name: provider-helm
105+
spec:
106+
package: xpkg.upbound.io/upbound/provider-helm:v0.20.2
107+
runtimeConfigRef:
108+
apiVersion: pkg.crossplane.io/v1beta1
109+
kind: DeploymentRuntimeConfig
110+
name: cert-bundle
111+
```
112+
113+
4. Confirm the Provider Installation and verify healthy by running:
114+
115+
```bash
116+
kubectl get provider.pkg
117+
```
118+
119+
Expected output:
120+
121+
```
122+
NAME INSTALLED HEALTHY PACKAGE AGE
123+
provider-helm True True xpkg.upbound.io/upbound/provider-helm:v0.20.2 13h
124+
```
125+
126+
To confirm the Provider pod is running in the `crossplane-system` namespace:
127+
128+
```bash
129+
kubectl get pods -n crossplane-system -l pkg.crossplane.io/provider=provider-helm
130+
```
131+
132+
Expected output:
133+
134+
```
135+
NAME READY STATUS RESTARTS AGE
136+
provider-helm-503c3591121b-54bfdb769c-rhg8w 1/1 Running 0 13h
137+
```
138+
139+
5. Verify the volume is mounted, doescribe the Provider pod:
140+
141+
```bash
142+
kubectl describe pod -n crossplane-system -l pkg.crossplane.io/provider=provider-helm
143+
```
144+
145+
Look for the following details in the output:
146+
```bash
147+
/etc/ssl/certs from cert-bundle (rw)
148+
```
149+
150+
```bash
151+
cert-bundle:
152+
Type: ConfigMap (a volume populated by a ConfigMap)
153+
Name: cert-bundle
154+
Optional: false
155+
```
156+
157+
This confirms the custom certificate bundle is properly mounted and in use.

0 commit comments

Comments
 (0)