-
Couldn't load subscription status.
- Fork 33
Description
I managed to get this working today after reviewing this issue and various other issues on this repository. Here's what I had to do:
A few variables that you'll need to customize that will be used throughout:
PROJECT_ID="account-id-1234"
ACCOUNT_EMAIL="your-email@wherever.com"Download the CRD and controller manifests and define a few patches to use with the controller via Kustomize (note that the config files are all ending up in a sub-directory called gke and that we leave that at the end of these commands).
mkdir gke; cd gke
curl --remote-name-all \
https://raw.githubusercontent.com/GoogleCloudPlatform/gke-managed-certs/v0.3.0/deploy/managedcertificates-crd.yaml \
https://raw.githubusercontent.com/GoogleCloudPlatform/gke-managed-certs/v0.3.0/deploy/managed-certificate-controller.yaml
cat > managed-certificate-controller-secrets.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: managed-certificate-controller
spec:
template:
spec:
containers:
- name: managed-certificate-controller
env:
- name: GOOGLE_APPLICATION_CREDENTIALS
value: "/var/run/credentials/service-account-key.json"
volumeMounts:
- name: google-application-credentials
mountPath: "/var/run/credentials"
readOnly: true
volumes:
- name: google-application-credentials
secret:
secretName: gke-managed-certs-credentials
EOF
cat > kustomization.yml <<EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- managedcertificates-crd.yaml
- managed-certificate-controller.yaml
patches:
- managed-certificate-controller-secrets.yaml
EOF
cd ..The above patch, managed-certificate-controller-secrets.yml, sets up so a volume will be mounted to access the secret file, and an environment variable has been defined that points to the file (as was shown is possible by @bmhatfield here). If you don't really know much about Kustomize, you can just edit the controller manifest manually. Here's the full manifest w/ the patch applied if this is confusing to you.
The next block of commands will take care of the following:
- Create a new service account that can be used for the controller.
- Create a custom role that will be assigned to that service account.
- Assign the required permissions (referred to as compute-rw by @krzykwas here and enumerated by @bmhatfield here) to the custom role.
- Export the keys for the service account so they can later be added as a Kubernetes secret.
gcloud iam service-accounts create gke-managed-certs \
--display-name "GKE Managed Certs"
gcloud iam roles create gke_managed_certs_role \
--project $PROJECT_ID \
--title "GKE Managed Certs Role" \
--description "Read & write permissions for GKE Managed Certs" \
--permissions compute.sslCertificates.create,compute.sslCertificates.delete,compute.sslCertificates.get,compute.sslCertificates.list \
--stage BETA
gcloud projects add-iam-policy-binding $PROJECT_ID \
--member serviceAccount:gke-managed-certs@$PROJECT_ID.iam.gserviceaccount.com \
--role projects/$PROJECT_ID/roles/gke_managed_certs_role
gcloud iam service-accounts keys create ./service-account-key.json \
--iam-account gke-managed-certs@$PROJECT_ID.iam.gserviceaccount.comCreate the container and get the kubectl context all set up as normal:
gcloud container clusters create \
--machine-type=g1-small \
--num-nodes=2 \
--disk-size=10GB \
ssl-test
gcloud container clusters get-credentials ssl-testNow start sending things off to your cluster via kubectl:
- Create the secret for the service account.
- Add the
cluster-adminrole to the executing user as explained here. - Deploy the GKE Managed Certs CRD and controller w/ the patches applied by using
kustomize. - Deploy an app alongside the
Ingressw/ the SSL annotations.
kubectl create secret generic gke-managed-certs-credentials \
--from-file=./service-account-key.json
kubectl create clusterrolebinding admin-binding \
--clusterrole=cluster-admin \
--user=$ACCOUNT_EMAIL
# this creates the CRD & controller w/ our patch
kustomize build ./gke | kubectl apply -f -
# deply a simple app w/ certs
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-world
spec:
replicas: 3
selector:
matchLabels:
app: hello-world
template:
metadata:
labels:
app: hello-world
spec:
containers:
- name: hello-world
image: gcr.io/google-samples/hello-app:1.0
---
apiVersion: v1
kind: Service
metadata:
name: hello-world
spec:
type: NodePort
selector:
app: hello-world
ports:
- protocol: TCP
port: 8080
---
apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
metadata:
name: ssl-test
spec:
domains:
- ssl-test.my-domain.com
---
apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
metadata:
name: ssl-test2
spec:
domains:
- ssl-test2.my-domain.com
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ssl-test
annotations:
networking.gke.io/managed-certificates: "ssl-test,ssl-test2"
spec:
backend:
serviceName: hello-world
servicePort: 8080
EOF
kubectl get ingress -wNow wait for your load balancer to be created & assigned an external IP address. At that point, you can update your DNS records to point to that IP & wait for the SSL cert to become active.
If you want to tear this down so you don't get billed:
kubectl delete service hello-world # allows the load balancer to be deleted
gcloud container clusters delete ssl-testNote that this does not delete the service account/role/keys that were created. Feel free to do that if you wish.
Originally posted by @wbyoung in #9 (comment)