Minimizing the use of the jsctl
CLI gives you more flexibility.
For example:
- You get to install whatever version of js-operator you desire
- You force yourself to get familiar with the controller's Installation manifest, which jsctl otherwise attempts to abstract away
k8s_name=kind-$(date +"%y%m%d%H%M")
cat <<EOF | kind create cluster --config -
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: ${k8s_name}
nodes:
- role: control-plane
EOF
k8s_name_tlspk=$(tr "-" "_" <<< ${k8s_name})
# rm -rf ~/.jsctl/ # (optional)
jsctl auth login
jsctl config set organization gallant-wright # (change org as appropriate)
jsctl registry auth init
This means we can install whichever version we want
kubectl create namespace jetstack-secure
dockerconfigjson=$(mktemp)
cat <<EOF > ${dockerconfigjson}
{"auths": {"eu.gcr.io": {"username": "_json_key","password": "$(cat ~/.jsctl/eu.gcr.io--jetstack-secure-enterprise.json | sed 's/\\n/\\CR/g' | sed 's/$/\\n/g' | sed 's/"/\\"/g' | tr -d '\n' | sed 's/\\CR/\\n/g')","email": "[email protected]","auth": "$(echo "_json_key:$(cat ~/.jsctl/eu.gcr.io--jetstack-secure-enterprise.json)" | base64)"}}}
EOF
kubectl -n jetstack-secure create secret docker-registry jse-gcr-creds \
--from-file .dockerconfigjson=$(echo ${dockerconfigjson})
helm upgrade --install js-operator \
oci://eu.gcr.io/jetstack-secure-enterprise/charts/js-operator \
--namespace jetstack-secure \
--version v0.0.1-alpha.24 \
--registry-config ${dockerconfigjson} \
--set images.secret.enabled=true \
--set images.secret.name=jse-gcr-creds \
--wait
This means we'll get the operator jsctl chooses (which may be old).
kubectl create namespace jetstack-secure
jsctl operator deploy --registry-credentials-path ~/.jsctl/eu.gcr.io--jetstack-secure-enterprise.json
kubectl create -f - << EOF
apiVersion: operator.jetstack.io/v1alpha1
kind: Installation
metadata:
creationTimestamp: null
name: jetstack-secure
spec:
approverPolicy: {}
certManager:
controller:
replicas: 1
webhook:
replicas: 1
images:
secret: jse-gcr-creds
EOF
jsctl operator installations apply --registry-credentials-path ~/.jsctl/eu.gcr.io--jetstack-secure-enterprise.json --cert-manager-replicas 1
This includes the Venafi(Cluster)Issuer and VenafiConnection CRDs
kubectl patch installation jetstack-secure --type merge --patch-file <(cat <<EOF
spec:
venafiEnhancedIssuer:
replicas: 1
EOF
)
jsctl clusters connect ${k8s_name_tlspk}
kind delete cluster --name ${k8s_name}
jsctl clusters delete ${k8s_name_tlspk} --force
jsctl auth login
createsconfig.json
(org empty) andtoken.json
inside~/.jscrtl/
jsctl config set organization <org>
fills config.jsonjsctl clusters connect ${k8s_name_tlspk}
needs KUBECONFIG in place, causes a TLSPK service account to be createdjsctl registry auth init
creates pull secret in TLSPK andeu.gcr.io--jetstack-secure-enterprise.json
inside~/.jscrtl/
jsctl operator deploy
will do theauth init
step when--auto-registry-credentials
is provided- To access swagger API at https://platform.jetstack.io/openapi/index.html use the access token from
~/.jsctl/token.json
Looking at the jsctl code for jsctl registry auth output --format=dockerconfig
we can see it's a client-side operation which reformats ~/.jsctl/eu.gcr.io--jetstack-secure-enterprise.json
. Look at jsctl/internal/registry/credentials.go (DockerConfigJSON) for more info. If we can perform this translation outside jsctl we get one step closer to eliminating it altogether.