Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable HTTPS for source artifact URL defined in .status.artifact.url #4

Open
11 tasks
rashedkvm opened this issue Aug 25, 2022 · 4 comments
Open
11 tasks
Labels
enhancement New feature or request

Comments

@rashedkvm
Copy link
Member

rashedkvm commented Aug 25, 2022

Enable TLS for source artifact download URL

The current implementation of source controller API ImageRepository and MavenArtifact expose the resulting source artifact at a HTTP URL defined in .status.artifact.url. The source artifact URL is not exposed externally and is only available to in-cluster consumers. This feature request requires TLS for the source artifact download endpoint.

Additional context
An accepted solution for this Proposal must include the requirements listed below.

  • Backward compatibility (i.e., deprecate HTTP URL and support existing clients during the deprecated period)
  • Support certificate signed by private CA
  • Able to consume certificate updates
  • In-cluster clients able to trust the certificate

Proposal

  • Add a fixed named secret that contains the TLS key and certificate
  • Source Controller manager deployment will use the secret in a mounted volume
  • Use cert-manager to issue a certificate and rotate expired certificates
  • Add a new type, SecureArtifact that has all the existing fields available in the existing Artifact type plus a new field called CABundle. The CABundle is a string field that contains the client certificate key/value pair
  • The URL field for SecureArtifact will contain the HTTPS download URL
  • Source Controller APIs Status will include SecureArtifact as well as existing Artifact and maintain backward compatibility

Here is a mock shape of the fixed name secret

apiVersion: v1
data:
  ca.crt: 
  tls.crt: 
  tls.key: 
kind: Secret
metadata:
  name: source-server-cert
  namespace: source-system
type: kubernetes.io/tls

Here is a mock of the proposed API status

status:
  artifact:                 # existing type `Artifact`
    ...
    url: "http://..."
  secureArtifact:           # New type `SecureArtifact` = `Artifact` + CABundle
    ...
    url: "https://..."
    caBundle: ""

Testing

  • Unit test coverage of the HTTPS feature
  • e2e integration test (CI)
  • Install with value TLS enabled
  • Create ImageRespository resource
  • Validate downloaded artifact from HTTPS endpoint
  • Create MavenArtifact resource
  • Validate downloaded maven artifact from HTTPS endpoint
@rashedkvm rashedkvm added the enhancement New feature or request label Aug 25, 2022
@kvmw
Copy link

kvmw commented Aug 25, 2022

PR vmware-tanzu/source-controller#307 has the initial implementation for this feature.

It enables source controller to use either HTTP or HTTPS. the default is HTTP, unless server private key and certificate is provided which enables HTTPS.

@rashedkvm
Copy link
Member Author

rashedkvm commented Aug 29, 2022

PR vmware-tanzu/source-controller#307 has the initial implementation for this feature.

It enables source controller to use either HTTP or HTTPS. the default is HTTP, unless server private key and certificate is provided which enables HTTPS.

@kvmw is this still the design/approach to enable HTTPS?

  • Does this approach work with cert-manager managing certificates?
  • With cert-manager managing certs, how is HTTPS disabled?

@kvmw
Copy link

kvmw commented Aug 29, 2022

  • yes, we have changed the code to use cert-manager to generate the self-signed certificate.
  • during installation with carvel tools, we can pass a data-value (enable_tls=true) to enable HTTPS. to disable HTTPS we can pass enable_tls=false or leave this value out. the default value is false.

@kvmw
Copy link

kvmw commented Aug 29, 2022

@rashedkvm using cert-manager we have met the following two requirements:

  • Support certificate signed by private CA
  • Able to consume certificate updates

We need to deal with backward compatibility and the client trust now.

@rashedkvm rashedkvm transferred this issue from another repository Jan 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants