IAM_and_zero_trust_architecture.md

Notes on IAM (Identity and Access Management) and Zero-Trust Architecture

Overall ideas

• Pervasive X.509 authentication with SPIFFE standards using the SPIRE reference implementation
• Frequent (e.g. hourly) rotation of dynamically-generated certificates for mTLS between nodes/workloads in the usual SPIFFE way
• In Kubernetes:
  • cert-manager with csi-driver-spiffe
  • k8s Workload Registrar — deprecated in favor of the spire-controller-manager
• Most workloads will use csi-driver-spiffe as described here to provide the SPIFFE_ENDPOINT_SOCKET evironment variable and the Java SPIFFE Provider to construct an SSLContext for their endpoint and call it a day (assuming the workload has been registered, e.g. via the k8s Workload Registrar).
• Like virtually all tools issuing X.509 certificates, SPIRE wants to be its own CA ("By default the SPIRE Server acts as its own certificate authority.") Strongly consider using SPIRE Server's cert-manager UpstreamAuthority plugin and integrating cert-manager with an internal ACME CA such as step-ca.
• For end-user authentication, consider selecting/creating a token translation service from OpenID Connect (OIDC) identity tokens to X.509 certificates, ideally following the AARC JRA1 4I Best practices and recommendations for attribute translation from federated authentication to X.509 credentials, in particular with respect to representing group/role membership.
  • INDIGO TTS, or even whole IdP?
  • Find or create an implementation of the sso-01 challenge for ACME. Consider that step-ca already gets very close, i.e. suggest SmallStep implement it or even implement it and offer a PR.
  • With step-ca, probably at least need to use X.509 templates to customize generated certificate to be a valid X.509-SVID.
  • Also probably need to register generated X.509-SVID with SPIRE, which would seem to entail generating a gRPC client using the SPIRE API SDK.

Minikube setup

1. Enable the ingress-dns Minikube addon. Do not enable the ingress addon, because it does not enable ssl-passthrough and patching the deployment does not survive Minikube restarts. Do not use a TLD of "localhost" as every browser I tested fails to resolve it correctly. I suggest using ".test" as your TLD.
2. Install step-certificates with helm install step-certificates smallstep/step-certificates --set ca.url='https://step-ca.test' --set ca.dns="step-ca.test\,step-certificates.default.svc.cluster.local\,127.0.0.1". The ca.url and ca.dns values are necessary to reflect how the "outside world" (from Minikube) identifies the service and, crucially, how the root_ca.crt will be generated.
3. Install step-cli.
4. Create an ingress to the step-certificates service including the ssl-passthrough annotations. The YAML should look like this:

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: step-ca-ingress
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  ingressClassName: nginx
  rules:
    - host: step-ca.test
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: step-certificates
                port:
                  number: 443

5. Execute kubectl -n default logs job.batch/step-certificates. Note the "CA URL" and "CA Fingerprint."
6. Execute step ca bootstrap --ca-url=<CA URL> --fingerprint=<CA Fingerprint>. Follow the dialogue.
7. Execute helm upgrade ingress-nginx ingress-nginx/ingress-nginx \ --install --create-namespace --version 4.1.4 \ --namespace ingress-nginx \ --set rbac.create=true \ --set "controller.extraArgs.enable-ssl-passthrough=" \ --set controller.hostNetwork=true \ --set "controller.extraArgs.report-node-internal-ip-address=". This chart version is compatible with Kubernetes 1.19+. I use it because, as of this writing, my understanding is Amazon's EKS (our production environment) is running Kubernetes 1.19.
8. Execute step ca health. You should get an "ok" response. If not, please ensure the ingress controller deployment was successfuly patched to support ssl-passthrough, the ingress object has the necessary annotations, step-certificates was installed with the right ca-url and ca-dns options, and the host and route in the ingress object match the ca-url and service name of the step-certificates service.
9. Execute helm repo add codecentric https://codecentric.github.io/helm-charts.
10. Execute helm install keycloak codecentric/keycloak.
11. Create an ingress to the keycloak service including the ssl-passthrough annotations. The YAML should look like this:

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: keycloak-ingress
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  ingressClassName: nginx
  rules:
    - host: keycloak.test
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: keycloak-http
                port:
                  number: 8443

12. Visit https://keycloak.test with your browser. Because Keycloak is using a self-signed certificate and we haven't done anything to provide trust in that certificate to your browser, you will be warned that the certificate can't be verified. Your browser will likely allow you to visit the site anyway, depending upon your security settings. Do so, and you should find yourself at Keycloak's dashboard where you can follow Keycloak's documentation about creating your admin user, etc.