What has to be done so that CA is exposed outside of K8s?

[mr-rooftop]

I see that in hlf-kube exists the possibility to enable ingress for the CA.

Does the setup for the CA ingress work the same way as the ingresses for orderer and peer in the cross-cluster guide? I.e.

1. first helm installation helm install stable/nginx-ingress --name hlf-ca-ingress --namespace kube-system --set controller.service.type=LoadBalancer --set controller.ingressClass=hlf-ca --set controller.service.ports.https=7054 --set controller.service.enableHttp=false --set controller.extraArgs.enable-ssl-passthrough=''

2. then enable CA ingress in the values.yaml and put some parentDomain there,

3. and finally collect_(external_)host_aliases.sh with some adaption to the scripts?

The annotations of the ingress imply that it is expected to have a letsencrypt-prod ClusterIssuer created by cert-manager. Do I have to do this manually and do I need an actual registered domain?

# common settings for CouchDB and CA ingresses
ingress:
  # all ingress subdomains will be created under this domain
  parentDomain: pivtdomain
  annotations:
    kubernetes.io/ssl-redirect: "true"
    cert-manager.io/cluster-issuer: letsencrypt-prod

The ssl-redirect: "true" seems to neutralize the enable-ssl-passthrough='' line that was given as a value to the imaginary helm install command above. Is this true?

---

The goal is to have one or multiple CAs exposed so that it's possible to enroll new users with the likes of a SDK.

As stated above, I got a few ideas where to start, and I already successfully exposed a HF CA in a different project. However maybe it's possible that you could state the exact changes that are needed for such CA exposure, because I'm sure I'll get stuck in some misconfiguration.

Best Regards!

PS: Once again a great project! Could upgrade to helm 3 and kubectl 1.16 without much of a hassle, and also the transition to HF 2.0 is almost done apart from the different chaincode lifecycle newly introduced.

[raftAtGit]

thanks for the nice words :)

you dont need that special Ingress setup for exposing CA's. this would be enough:

helm install stable/nginx-ingress --set controller.service.type=LoadBalancer

CA's will be accessible at:

hlf-ca-<org-name>.<ingress.parentDomain>

You need to register your parent domain and all A type DNS records *.parentDomain should point to LoadBalancer IP of Ingress. o/w you can use your local DNS trick (/etc/hosts/ for example) to point those domains to Ingress LoadBalancer IP.

Note, you need to actually register your domain to use cert manager. o/w set kubernetes.io/ssl-redirect: "false"

[sillysachin]

PS: Once again a great project! Could upgrade to helm 3 and kubectl 1.16 without much of a hassle, and also the transition to HF 2.0 is almost done apart from the different chaincode lifecycle newly introduced.

Can you please share your HF 2.x changes for learning!

[mr-rooftop]

Hey @sillysachin ! The changes to get it to work with HF 2.0 were pretty straight forward.

Just search the whole project folder for 1.4.3 as this is the HF that's used for this repo. Or look for version in config files that indicate the HF version. Then change the version when appropriate to 2.0 (You could already use 2.1)

To use 2.0 chaincode lifecycle however, more has to be done. I'm currently trying to figure out how to modify the current workflows to comply with the 2.0 lifecycle.

Beware that HF 2.0 container use Alpine Linux, which seems that by default does not use bash (bourne again shell) but only sh (shell?). Some shell commands behave differently when you connect to the container.

Bonus: To use helm3, nothing other has to be done than to adjust the order and/or name of the flags or the helm command line commands according to the helm3 specification. No modification in any files has to be done. E.g. you go from (helm2)

helm install stable/nginx-ingress --name hlf-peer-ingress --namespace kube-system --set controller.service.type=LoadBalancer --set controller.ingressClass=hlf-peer --set controller.service.ports.https=7051 --set controller.service.enableHttp=false --set controller.extraArgs.enable-ssl-passthrough=''

to (helm3):

helm install stable/nginx-ingress --name hlf-peer-ingress --namespace kube-system --set controller.service.type=LoadBalancer --set controller.ingressClass=hlf-peer --set controller.service.ports.https=7051 --set controller.service.enableHttp=false --set controller.extraArgs.enable-ssl-passthrough=''

[sillysachin]

Yes. How to modify the current workflows to comply with the 2.0 lifecycle This is where my lack of prior experience with this tool chain has stopped me.

[mr-rooftop]

Ah, I didn't have working lifecycle until recently. Check out it here.

[sillysachin]

@mr-rooftop - Can i reach you on email or linkedin? http://linkedin.com/in/sachinshekharr/

[abhisamant7]

thanks for the nice words :)

you dont need that special Ingress setup for exposing CA's. this would be enough:

helm install stable/nginx-ingress --set controller.service.type=LoadBalancer

CA's will be accessible at:

hlf-ca-<org-name>.<ingress.parentDomain>

You need to register your parent domain and all A type DNS records *.parentDomain should point to LoadBalancer IP of Ingress. o/w you can use your local DNS trick (/etc/hosts/ for example) to point those domains to Ingress LoadBalancer IP.

Note, you need to actually register your domain to use cert manager. o/w set kubernetes.io/ssl-redirect: "false"

Hi @raftAtGit,

I am also trying to achieve this one however I am getting issue. May be I am missing something which need to enable. so could you please elaborate little more as I am new to k8s stuffs.

Thanks in advance.

[Marek00Malik]

Hello guys, can someone help me with this one? I'm trying to expose CA and as I'm still running k8s locally assess it from localhost.

I have followed the instructions mentioned by @mr-rooftop :

1. first helm installation helm install stable/nginx-ingress --name hlf-ca-ingress --namespace kube-system --set controller.service.type=LoadBalancer --set controller.ingressClass=hlf-ca --set controller.service.ports.https=7054 --set controller.service.enableHttp=false --set controller.extraArgs.enable-ssl-passthrough=''
2. then enable CA ingress in the values.yaml and put some parentDomain there,
3. and finally collect_(external_)host_aliases.sh with some adaption to the scripts?

The last step is a bit questioning to me, I'm not running any external cluster, only one at the moment. Besides running he collects external hosts return nothing and running the default one does not include ca in the result.

I have my values.yaml as follows:

# Default values for hlf-kube.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

hyperledgerVersion: 2.2.1
hyperledgerCaVersion: 1.4.9

# see the Raft sample in the README for how to enable TLS
tlsEnabled: true

# use actual domain names like peer0.atlantis.com instead of internal service names
# this should be set to true for TLS
useActualDomains: true

# adds additional DNS entries to /etc/hosts files
# see https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/#adding-additional-entries-with-hostaliases
# this value should be provided if either tlsEnabled or useActualDomains is set to true
# see the Raft sample in the README for how to use this
hostAliases: []

# common persistence settings
persistence:
  storageClass: # default

backup:
  # initiate backup procedure?
  enabled: false
restore:
  # initiate restore procedure?
  enabled: false

# common settings for CouchDB and CA ingresses
ingress:
  # all ingress subdomains will be created under this domain
  parentDomain: amvox.io
  annotations:
    kubernetes.io/ssl-redirect: "false"
    cert-manager.io/cluster-issuer: letsencrypt-prod
...
# CA (Certificate Authority) settings. applies to all CA's
ca:
  userName: admin
  password: adminpw
  logLevel: info
  parentDomain: amvox
  ingress:
    enabled: true
    annotations:
      # this should match the ingressClass when orderer ingress controller is created
      kubernetes.io/ssl-redirect: "true"
      kubernetes.io/ingress.class: "hlf-ca"

In the addition to the steps above, I have also installed the Nginx-ingress controller to be used with docker-for-mac.

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.41.0/deploy/static/provider/cloud/deploy.yaml

The result is that the orderer controller is operating, but the both peer & ca are in pending state.

➜  fabric-kube git:(master) ✗ kubectl -n kube-system get svc -l app=nginx-ingress,component=controller
NAME                                           TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
hlf-ca-ingress-nginx-ingress-controller        LoadBalancer   10.99.75.166    <pending>     7054:32285/TCP   53m
hlf-orderer-ingress-nginx-ingress-controller   LoadBalancer   10.99.180.233   localhost     7050:30512/TCP   53m
hlf-peer-ingress-nginx-ingress-controller      LoadBalancer   10.101.202.72   <pending>     7051:30036/TCP   53m

[Marek00Malik]

Ok, ignore that problem. I think I messed up the configuration a bit. setting kubernetes.io/ssl-redirect: "false" in the common ingress section fixed the setup. Now I'm trying to connect to the cluster from my api from my local machine.