Currently Istio CA uses hard-coded organization (istio.io) for self-signed certificates. We need to make this configurable so user can use their own org.

Currently, the way we rotate Istio key and certificate is to let a proxy agent watch the files and restart the proxy to pick up the refreshed key and certificate. This is implemented as a short-term solution in istio/old_pilot_repo#663.

Ultimately we need a way to rotate these keys and certificates without restarting proxy. This is currently tracked by this issue (envoyproxy/envoy#891) in upstream Envoy repo.

Currently we only save key and cert into secret. Instead we should save the following three items:

• Key pair
• Certificate chain
• Root certificate

Currently the listeners are based on destination address (IP + port). Both IP and port may change by k8s. Which means we need to figure out the proper destination to use.

According to @kyessenov, we have all necessary IP (service IP, pod IP) and port (target port and pod port) info. So we can list all possible combinations in the listeners. In that case, it should work.

But in the long run, we may add some change at envoy side to let listener take a list of address instead of just one.

This is a tracking issue to enable service to service authorization at cluster level

This requires Envoy to forward auth results to next hop. It is tracked by:
envoyproxy/envoy#794
After that, Istio should configure:

1. For Side-car proxies, they always forward auth result to the backend.
2. For cluster ingress controllers, when external service uses mTLS to call ingress controllers, the latter always forwards the auth result of to the next hop.

Previously this repo only generate one executable istio-ca and the directory structure is relatively simple and flat. However, with the addition of node-agent, we should re-factor this repo to make code better organized.

There are currently two proposals

1. Follow the one used in kubernetes project, where binaries are placed into a top-level cmd/ directory. See here. The main files/methods in the cmd/ dir mainly deal with CLI parsing while the actually logic is implemented in related packages under pkg/. The overall structures would look like

istio.io/auth/
  cmd/
    istio_ca/
    node_agent/
    ....
  pkg/
    controller/
    .....

2. Use the one suggested by cobra. For example the directory structure would have:

istio.io/auth/
  istio_ca
    cmd/
    ... any other dirs...
    BUILD
    main.go
  node_agent/
    ...

cc @sarvaniv @myidpt @wattli

Istio proxy needs to support LOAS auth in GCP, which relies on the GCP Metadata service

We should make CertOptions.Host optional to avoid setting SAN field when generating CA certificates.

Tracking issue

Manager, proxy and other repos even the postsubmit of auth use Jenkins, it would be nice if we can move presubmit of auth into Jenkins. It makes sharing scripts and tools more easily.

Istio auth needs a component for certificate issuance. Basic functionalities should include:

• If a signing key & certificate are provided (via command line), use them as CA root key and cert. Otherwise, generate a key & certificate automatically
• Has an interface to create key & certificate when provided with a Kubernetes service account (name + namespace)

Currently we're using "github.com/istio/auth" as the go prefix. However we should switch to "istio.io/auth" to stay consistent other repos under Istio organization.

When Istio auth is enabled, Istio proxy should extract peer identity from certificates and forward the identity to Mixer.

We should add basic e2e tests for istio-ca. The tests should cover

• When deployed to a Kubernetes cluster, secrets are correctly created for existing service account
• Creating a new service account leads to the creation of corresponding secret
• Cert in created secret can be successfully verified
• Istio-ca re-creates secret when one is deleted.

Currently we only use go fmt to check basic source code formatting. We should switch to GoMetaLinter to have more comprehensive checks.

Currently TestGetPodServices fails occasionally. We should investigate and fix this flakiness.

Istio auth uses Kubernetes service account as Istio identity. To enable this, we need a secure naming service that maps a Kubernetes service into a set of service accounts whose pods are part of the service. This could be done by watching the kube-apiserver for creation/update/deletion of both pods and services.

Per the design of Istio auth, we should monitor the creation of Kubernetes service account and automatically create a key and certificate pair by calling into the certificate issuance API ( #1 ). The key and certificate are used to establish secure connection/channel between two Istio proxies.

Currently an Envoy listener is bound to an address (ip:port pair). Due to k8s address translation, we may need to have multiple addresses bound to the same listener.

Not a blocking issue since we can just duplicate the listener content for now. Will consult with Matt soon.

Integrate with existing CA in K8s, and provide gRPC interface to take CSR. Maintain a config file for istio identity assignment.

Sub tasks:

• Allow Istio CA to run as a GRPC server (#213, #216)
• Handle client authentication (e.g. GCP ID token, certificate)

Currently we are hard-coding rsaBits to 2048 in generate_cert.go. Instead we should make the key size configurable in CertOptions such that we can use a large key for CA cert and a smaller key for leaf cert.

Use Manager example
https://github.com/istio/manager/blob/master/cmd/version/version.go
https://github.com/istio/manager/blob/master/bin/get_workspace_status
https://github.com/istio/manager/blob/master/tools/bazel.rc

There are basically 3 scenarios in the deployment of Istio Auth:

1. There are no apps/proxies, we want to deploy apps and proxies (with Auth enabled).

2. Apps running without proxies, we want to deploy proxies (with Auth enabled)

3. Apps running with proxies (but without Auth enabled), we want to deploy proxies (with Auth enabled)

Need to investiagation the deployment flow of each of the scenario.

Setup: browser->ingress-envoy->productpage->[details|review(s)]->rating

1. productpage -> details mTLS is working fine. Verified using: https://istio.io/docs/tasks/ingress.html
2. TLS between browser->ingress proxy working.
3. mTLS between ingress proxy -> productpage is NOT working.
   Version: 0.1.5
   I have configured all the pod's with the same service accounts. If the service account of ingress-proxy and the productpage is not same then ingress proxy does NOT try to setup a mTLS session at all.
   But even with the service account being same (which is what the logs here have) the ssl session does NOT establish between ingress and productpage.

clusters-ingress-envoy.txt
ingress-envoy-json.txt

istio-auth-yaml.txt
istio-bookinfo-yaml.txt

According to Louis, we can test auth more by checking the mixer log.

We should check the copyright header in Travis CI to avoid accidentally committing new files without the headers.

When we rotate key/cert, we have 2 options 1) keep the same name 2) use a different name.

The first option is simpler since we don't need to update envoy config in this case. But it may have problems:

If envoy directly reads cert/key from file every time when they need them, then we are fine. However, if they keep the cert/key in memory or use some cache, the new key/cert with the same file name will not be able to populate. In that case, we need to go with the second option.

I am investigating on this.

• CA running on K8s (as Alpha does), provides a gRPC interface, maintain a config list
• VM node sends CSR, get cert

Currently we use Update instead of Create to avoid dealing with existing secrets. However we need to handle this more properly.

Relevant code is here: https://github.com/istio/auth/blob/master/controller/secret.go#L121

"allow-all": No secure naming is checked.
"all-none": Secure naming is checked against an empty list of service accounts. So it always fails.

We need to verify whether Envoy supports the two cases through config. Ideally, an undefined verify_subject_alt_name field should mean "allow-all" and a defined but empty verify_subject_alt_name field should mean "allow-none".

We should use bazel instead of glide as the build/dependency-management system as it provides a rich set of functionalities.

we may consider supporting "let's encrypt" to auto provision FQDN cert to support end user traffic, or peer service that doesn't run istio proxy and doesn't support spiffe.

We should add comments to the secure naming component to make it more readable.

We currently don't have test coverage for https://github.com/istio/auth/tree/master/certmanager