BookmarkSubscribeRSS Feed
☑ This topic is solved. Need further help from the community? Please sign in and ask a new question.
TeeHammed
Fluorite | Level 6

Hello all,

I'm in the process of deploying SAS Viya, but I have run into a bit of a dilemma and I really need some help, please.

 

I'm on the CADENCENAME: stable. and CADENCEVERSION:2023.03

 

I'm deploying SAS Viya using the SAS Viya Platform Deployment Operator, and everything works just fine, except that when I try to connect to the application via my ingress definition, I don't get any TLS protection on the endpoint. I'm able to connect and log in, I just get the TLS self-signed warning on the browser.

 

When I run a kubectl describe on one of the ingress definitions created as part of my SAS Viya deployment, this is what I get back.

Annotations: cert-manager.io/issuer: sas-viya-issuer
             nginx.ingress.kubernetes.io/affinity: cookie
             nginx.ingress.kubernetes.io/affinity-mode: persistent
             nginx.ingress.kubernetes.io/backend-protocol: HTTPS

And I suspect that the default sas-viya-isser issuer being used, is what's causing the problem as it's using a self-signed certificate.

However, I am unable to use my own created issuer.

 

I've tried adding this line to the transformers section of my kustomization file

- site-config/security/ingress-annotation-transformer.yaml

And the contents of the file is

---
apiVersion: builtin
kind: PatchTransformer
metadata:
  name: sas-cert-manager-ingress-annotation-transformer
patch: |-
  - op: add
    path: /metadata/annotations/cert-manager.io~1issuer
    value: custom-issuer
target: kind: Ingress name: .*

However, when I do this, the pods do not even come up at all, instead, I get an error that the sas-viya-ca-certificate-secret cannot be found and I don't understand why, as I expected it to simply replace the annotation on my ingress definition to use my custom-issuer.

 

When I leave this as the default

The custom-issuer which is an issuer and not a cluster-issuer, exists and I have validated that it works, by creating an Ingress and service in that namespace, and I'm able to access the hostname via a browser and it's TLS protected as I would expect.


For some reason though, it doesn't work with SAS Viya.

Is there a way to use my custom issuer or cluster issuer with SAS Viya as opposed to the default sas-viya-isser issuer that comes out of the box?

 

Any suggestions or pointers would be much appreciated.

 

Thanks a lot

1 ACCEPTED SOLUTION

Accepted Solutions
gwootton
SAS Super FREQ
Self-signed certificates are still encrypted so you still have TLS protection of the endpoint.

Those names are hard-coded into the TLS objects when you source full-stack-tls or front-door-tls, which the sas-certframe initContainer uses. This container does things like staging the trust store for each pod and requesting or generating internal certificates to secure communication between pods (full stack TLS).

You would probably need to edit the sas-certframe-user-config configMap with the appropriate values for your deployment, though this is not a supported configuration. The supported configurations with Cert-Manager would be for us to create the self-signed certificate and key or it to already exist so we only need to create the sas-viya-issuer.

Configure Cert-Manager Certificate Generator
https://go.documentation.sas.com/doc/en/sasadmincdc/v_038/calencryptmotion/n1xdqv1sezyrahn17erzcunxw...

Typically if you don't want self-signed and need to supply a site-signed certificate you would provide that in customer-provided-ca-certificates.yaml and customer-provided-ingress-ceritficate.yaml files, then use cert-manager or openssl to have SAS generate the certificates for inter-pod (full stack) TLS.
--
Greg Wootton | Principal Systems Technical Support Engineer

View solution in original post

1 REPLY 1
gwootton
SAS Super FREQ
Self-signed certificates are still encrypted so you still have TLS protection of the endpoint.

Those names are hard-coded into the TLS objects when you source full-stack-tls or front-door-tls, which the sas-certframe initContainer uses. This container does things like staging the trust store for each pod and requesting or generating internal certificates to secure communication between pods (full stack TLS).

You would probably need to edit the sas-certframe-user-config configMap with the appropriate values for your deployment, though this is not a supported configuration. The supported configurations with Cert-Manager would be for us to create the self-signed certificate and key or it to already exist so we only need to create the sas-viya-issuer.

Configure Cert-Manager Certificate Generator
https://go.documentation.sas.com/doc/en/sasadmincdc/v_038/calencryptmotion/n1xdqv1sezyrahn17erzcunxw...

Typically if you don't want self-signed and need to supply a site-signed certificate you would provide that in customer-provided-ca-certificates.yaml and customer-provided-ingress-ceritficate.yaml files, then use cert-manager or openssl to have SAS generate the certificates for inter-pod (full stack) TLS.
--
Greg Wootton | Principal Systems Technical Support Engineer