From 066999ed88b4ed708578f449f9f5021bf7010372 Mon Sep 17 00:00:00 2001 From: paulternate Date: Tue, 21 Nov 2023 10:48:29 -0800 Subject: [PATCH] Deployed f577cee with MkDocs version: 1.4.2 --- .../0-intro-hsm-utility/index.html | 2 +- .../1-usage-hsm-utility/index.html | 2 +- Tools/HSM-Utility/2-Cryptoki-Use/index.html | 2 +- search/search_index.json | 2 +- sitemap.xml | 102 +++++++++--------- sitemap.xml.gz | Bin 825 -> 824 bytes 6 files changed, 55 insertions(+), 55 deletions(-) diff --git a/Tools/HSM-Utility/0-intro-hsm-utility/index.html b/Tools/HSM-Utility/0-intro-hsm-utility/index.html index 1e0ac34..f7cf596 100644 --- a/Tools/HSM-Utility/0-intro-hsm-utility/index.html +++ b/Tools/HSM-Utility/0-intro-hsm-utility/index.html @@ -583,7 +583,7 @@

HSM Validation UtilityΒΆ

-

Venafi Trust Protection Platform supports integrations with Hardware Security Modules (HSMs) to encrypt private keys, credentials, and other secrets stored in the database. +

Venafi TLS Protect Datacenter (formerly known as Trust Protection Platform)supports integrations with Hardware Security Modules (HSMs) to encrypt private keys, credentials, and other secrets stored in the database. Users can also use the HSM integration for the central generation of private keys.

To be listed in the Venafi documentation as a compatible HSM provider, it's important to test and validate each use case that your HSM supports:

    diff --git a/Tools/HSM-Utility/1-usage-hsm-utility/index.html b/Tools/HSM-Utility/1-usage-hsm-utility/index.html index 43bfe74..2c0bb43 100644 --- a/Tools/HSM-Utility/1-usage-hsm-utility/index.html +++ b/Tools/HSM-Utility/1-usage-hsm-utility/index.html @@ -631,7 +631,7 @@
- +

This content is protected with AES encryption.

diff --git a/Tools/HSM-Utility/2-Cryptoki-Use/index.html b/Tools/HSM-Utility/2-Cryptoki-Use/index.html index 226e4b0..bf25815 100644 --- a/Tools/HSM-Utility/2-Cryptoki-Use/index.html +++ b/Tools/HSM-Utility/2-Cryptoki-Use/index.html @@ -651,7 +651,7 @@
- +

This content is protected with AES encryption.

diff --git a/search/search_index.json b/search/search_index.json index 1b0df1c..9860cc3 100644 --- a/search/search_index.json +++ b/search/search_index.json @@ -1 +1 @@ -{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"","title":"Home"},{"location":"nav/","text":"Home Getting Started Developers Tools Manifesto Marketplace","title":"Nav"},{"location":"Developers/devs-glossary/","text":"Glossary \u00b6 Term Definition Certificate Authority An entity that signs, and issues digital certificates CRD Custom Resource Definition: an extension of the Kubernetes API Downtime A period of time where the workload is unintentionally inaccessible Ingress Controller Specialized load balancers for Kubernetes and other containerized environments Machine Identity X.509 certificates, SSH keys, code signing certificates, etc., used to secure applications, traffic, code & organizations Machine Identity Management Control Plane The holistic platform/service, along with the cultivation & curation of the vast marketplace of solutions, tools & frameworks offered by Venafi and the ecosystem TLS Protect Cloud Venafi's SaaS offering (formerly known as Venafi as a Service) TLS Protect Datacenter Venafi's Datacenter offering (formerly known as Trust Protection Platform TLS Protect For Kubernetes Jetstack's SaaS offering (formerly known as Jetstack Secure) WAF Web Application Firewall: used to protect web apps from malicious traffic Workloads A process or any location where compute resources are consumed. Workloads in Kubernetes are pods","title":"Glossary"},{"location":"Developers/devs-glossary/#glossary","text":"Term Definition Certificate Authority An entity that signs, and issues digital certificates CRD Custom Resource Definition: an extension of the Kubernetes API Downtime A period of time where the workload is unintentionally inaccessible Ingress Controller Specialized load balancers for Kubernetes and other containerized environments Machine Identity X.509 certificates, SSH keys, code signing certificates, etc., used to secure applications, traffic, code & organizations Machine Identity Management Control Plane The holistic platform/service, along with the cultivation & curation of the vast marketplace of solutions, tools & frameworks offered by Venafi and the ecosystem TLS Protect Cloud Venafi's SaaS offering (formerly known as Venafi as a Service) TLS Protect Datacenter Venafi's Datacenter offering (formerly known as Trust Protection Platform TLS Protect For Kubernetes Jetstack's SaaS offering (formerly known as Jetstack Secure) WAF Web Application Firewall: used to protect web apps from malicious traffic Workloads A process or any location where compute resources are consumed. Workloads in Kubernetes are pods","title":"Glossary"},{"location":"Developers/devs-welcome/","text":"Welcome Developers \u00b6 This is where you'll find everything you need to develop new and exciting solutions focused on machine identity management. There are design patterns for getting started on your use case as quickly as possible, code examples, doc examples, Venafi libraries in the language of your choice, and more. If you see anything missing, please let us know . Getting Started \u00b6 If you've already got an idea about what you'd like to build in mind, but aren't sure where to start, please click here to answer a few questions that will help. If you already know the path your development will take, or you've been here before, the links are to the left.","title":"Welcome"},{"location":"Developers/devs-welcome/#welcome-developers","text":"This is where you'll find everything you need to develop new and exciting solutions focused on machine identity management. There are design patterns for getting started on your use case as quickly as possible, code examples, doc examples, Venafi libraries in the language of your choice, and more. If you see anything missing, please let us know .","title":"Welcome Developers"},{"location":"Developers/devs-welcome/#getting-started","text":"If you've already got an idea about what you'd like to build in mind, but aren't sure where to start, please click here to answer a few questions that will help. If you already know the path your development will take, or you've been here before, the links are to the left.","title":"Getting Started"},{"location":"Developers/nav/","text":"Welcome Glossary Design Patterns Certification","title":"Nav"},{"location":"Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/","text":"Certification - TLS Protect Cloud \u00b6 This page is meant to be your home base throughout the certification process, so please feel free to jump around, read ahead, bookmark and come back to it as needed. Ready to certify? If you've already completed your solution, understand and meet the necessary requirements and are ready to submit a request for Certification, you can start here. Introduction \u00b6 As a TLS Protect Cloud Certified solution, Venafi users have an extra level of confidence that your solution was designed with their best interests at the forefront. For that reason, certified solutions see more adoption from our mutual users. When building an solution to TLS Protect Cloud , one desired outcome should be official certification. Official certification is the first step to listing the solution on the Venafi Marketplace , which is the #1 way end users discover and deploy solutions. Certification is the only way that an solution will be listed on the Venafi Marketplace as compatible with TLS Protect Cloud . The TLS Protect Cloud Certification Program is still evolving and so some specifics about the following requirements are subject to change. Ample notice will be given to any developers of an existing certified solution, ensuring plenty of time to make any necessary updates to maintain certification. The following requirements are applicable to every TLS Protect Cloud solution, however there may be additional, unlisted requirements depending on the specific use case of the solution. There will be solutions and use cases that come forward that are totally new and unique from every solution that has gone through the certification process - and that's GREAT! It means machine identity management is continuing to evolve and see continued adoption. We're all in this together In cases where the Venafi team requests additional requirements be met, we will work with you to determine what success looks like and do our best to provide any Tools/guidance necessary to reach certification. Technical Certification vs. Partner Program \u00b6 The technical certification process is not to be confused with Venafi Partnership, though the two are related. The best way to think about it would be \"Packaging\" vs. \"Marketing\". Packaging \u00b6 The final step of the TLS Protect Cloud certification process will be Packaging - deciding how end users will deploy and interact with your solution. In order for end users to discover the solution and establish a strong user base, the packaging of the solution should be polished and easy to understand. Use of company logos, iconography, product names, marketing copy, etc. will all help users quickly identify your solution in the growing Venafi Marketplace . Marketing \u00b6 Marketing , on the other hand, focuses on bringing attention to a fully packaged & published solution. Once the solution has been certified and the initial Marketplace Listing has been created, the next logical step would be an official partnership with Venafi, which will also engage the Venafi Marketing team to start making some noise about the new solution available to Venafi users.","title":"TLS Protect Cloud"},{"location":"Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/#certification-tls-protect-cloud","text":"This page is meant to be your home base throughout the certification process, so please feel free to jump around, read ahead, bookmark and come back to it as needed. Ready to certify? If you've already completed your solution, understand and meet the necessary requirements and are ready to submit a request for Certification, you can start here.","title":"Certification - TLS Protect Cloud"},{"location":"Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/#introduction","text":"As a TLS Protect Cloud Certified solution, Venafi users have an extra level of confidence that your solution was designed with their best interests at the forefront. For that reason, certified solutions see more adoption from our mutual users. When building an solution to TLS Protect Cloud , one desired outcome should be official certification. Official certification is the first step to listing the solution on the Venafi Marketplace , which is the #1 way end users discover and deploy solutions. Certification is the only way that an solution will be listed on the Venafi Marketplace as compatible with TLS Protect Cloud . The TLS Protect Cloud Certification Program is still evolving and so some specifics about the following requirements are subject to change. Ample notice will be given to any developers of an existing certified solution, ensuring plenty of time to make any necessary updates to maintain certification. The following requirements are applicable to every TLS Protect Cloud solution, however there may be additional, unlisted requirements depending on the specific use case of the solution. There will be solutions and use cases that come forward that are totally new and unique from every solution that has gone through the certification process - and that's GREAT! It means machine identity management is continuing to evolve and see continued adoption. We're all in this together In cases where the Venafi team requests additional requirements be met, we will work with you to determine what success looks like and do our best to provide any Tools/guidance necessary to reach certification.","title":"Introduction"},{"location":"Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/#technical-certification-vs-partner-program","text":"The technical certification process is not to be confused with Venafi Partnership, though the two are related. The best way to think about it would be \"Packaging\" vs. \"Marketing\".","title":"Technical Certification vs. Partner Program"},{"location":"Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/#packaging","text":"The final step of the TLS Protect Cloud certification process will be Packaging - deciding how end users will deploy and interact with your solution. In order for end users to discover the solution and establish a strong user base, the packaging of the solution should be polished and easy to understand. Use of company logos, iconography, product names, marketing copy, etc. will all help users quickly identify your solution in the growing Venafi Marketplace .","title":"Packaging"},{"location":"Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/#marketing","text":"Marketing , on the other hand, focuses on bringing attention to a fully packaged & published solution. Once the solution has been certified and the initial Marketplace Listing has been created, the next logical step would be an official partnership with Venafi, which will also engage the Venafi Marketing team to start making some noise about the new solution available to Venafi users.","title":"Marketing"},{"location":"Developers/Certification/TLS-Protect-Cloud/2-tlsp-certification-reqs/","text":"Requirements \u00b6 There are currently two levels of certification for TLS Protect Cloud solutions, Foundation Certification and Advanced Certification . It's our hope that every developer strives for the most comprehensive solution, but understand that isn't always possible due to resource and/or time constraints. The purpose of creating multiple levels of certification is two-fold: It provides a lower barrier to entry for smaller organizations and individual contributors It provides an opportunity for developers to further differentiate their solution by providing additional collateral that will help end users get started #fastsecure when using the solution. Meeting the requirements for Foundation Certification should be the first point of focus for any new developer. These requirements have been designed to create a simple pathway for developers to get a listing onto the Venafi Marketplace, while ensuring a consistent, stable experience for all TLS Protect Cloud end users. All TLS Protect Cloud solutions that are published on the Venafi Marketplace are required to meet the requirements for Foundation Certification. Advanced Certification provides a means to differentiate an solution that goes above & beyond the requirements specified above. Functionally, both Foundation Certification and Advanced Certification have the same technical requirements. The difference between the two levels is really about end user enablement and ongoing testing to ensure the solution remains fully functional. From an end user's perspective, generally the more collateral available to be consumed, the less likely end users are to have questions that might block them from testing and ultimately utilizing the solution. The easier it is to deploy and test the solution, the more widely adopted that solution becomes throughout the user base. More users generate more feedback and ideas, and the solution becomes more robust as a result. Certification Requirements \u00b6 Foundation Advanced The description of the solution is an accurate representation of functionality. The solution doesn't interfere with TLS Protect Cloud native functionality or performance. The solution was developed with overall security best practices in mind and makes no attempts to harvest user data. The solution uses generally available interfaces to interact with TLS Protect Cloud (VCert, REST API, etc.). Accompanying documentation must be packaged with the solution and should include any necessary configuration instructions as well as clear usage examples. Templates are provided for this purpose. ( NOTE: a free Venafi Account will be required to access this resource) The support model is clearly defined for all user types. A demonstration of all documented functionality must be scheduled & completed with the Venafi Ecosystem team. Everything listed in the Foundation Certification Requirements section tab be completed, in addition to the following: A 5-10 minute technical demonstration video covering any initial configuration and typical usage examples must be available online. When necessary, and if possible/feasible for the solution, a test instance or account will be provided to the Venafi Ecosystem team for internal testing and demonstration purposes. Automated testing must be put in place to test all documented functionality of your solution. All REST endpoints and/or VCert functions used by the solution must be documented and provided to Venafi. These will be used internally by Venafi to track which features & functions are being used most by developers and end users. They will not be shared publicly. Do you have feedback about the certification process? We've tried to make the certification process as simple and pain free as possible, but we're always looking to make it better. If you have any suggestions or feedback to improve the process, we'd love to hear them !","title":"Requirements"},{"location":"Developers/Certification/TLS-Protect-Cloud/2-tlsp-certification-reqs/#requirements","text":"There are currently two levels of certification for TLS Protect Cloud solutions, Foundation Certification and Advanced Certification . It's our hope that every developer strives for the most comprehensive solution, but understand that isn't always possible due to resource and/or time constraints. The purpose of creating multiple levels of certification is two-fold: It provides a lower barrier to entry for smaller organizations and individual contributors It provides an opportunity for developers to further differentiate their solution by providing additional collateral that will help end users get started #fastsecure when using the solution. Meeting the requirements for Foundation Certification should be the first point of focus for any new developer. These requirements have been designed to create a simple pathway for developers to get a listing onto the Venafi Marketplace, while ensuring a consistent, stable experience for all TLS Protect Cloud end users. All TLS Protect Cloud solutions that are published on the Venafi Marketplace are required to meet the requirements for Foundation Certification. Advanced Certification provides a means to differentiate an solution that goes above & beyond the requirements specified above. Functionally, both Foundation Certification and Advanced Certification have the same technical requirements. The difference between the two levels is really about end user enablement and ongoing testing to ensure the solution remains fully functional. From an end user's perspective, generally the more collateral available to be consumed, the less likely end users are to have questions that might block them from testing and ultimately utilizing the solution. The easier it is to deploy and test the solution, the more widely adopted that solution becomes throughout the user base. More users generate more feedback and ideas, and the solution becomes more robust as a result.","title":"Requirements"},{"location":"Developers/Certification/TLS-Protect-Cloud/2-tlsp-certification-reqs/#certification-requirements","text":"Foundation Advanced The description of the solution is an accurate representation of functionality. The solution doesn't interfere with TLS Protect Cloud native functionality or performance. The solution was developed with overall security best practices in mind and makes no attempts to harvest user data. The solution uses generally available interfaces to interact with TLS Protect Cloud (VCert, REST API, etc.). Accompanying documentation must be packaged with the solution and should include any necessary configuration instructions as well as clear usage examples. Templates are provided for this purpose. ( NOTE: a free Venafi Account will be required to access this resource) The support model is clearly defined for all user types. A demonstration of all documented functionality must be scheduled & completed with the Venafi Ecosystem team. Everything listed in the Foundation Certification Requirements section tab be completed, in addition to the following: A 5-10 minute technical demonstration video covering any initial configuration and typical usage examples must be available online. When necessary, and if possible/feasible for the solution, a test instance or account will be provided to the Venafi Ecosystem team for internal testing and demonstration purposes. Automated testing must be put in place to test all documented functionality of your solution. All REST endpoints and/or VCert functions used by the solution must be documented and provided to Venafi. These will be used internally by Venafi to track which features & functions are being used most by developers and end users. They will not be shared publicly. Do you have feedback about the certification process? We've tried to make the certification process as simple and pain free as possible, but we're always looking to make it better. If you have any suggestions or feedback to improve the process, we'd love to hear them !","title":"Certification Requirements"},{"location":"Developers/Certification/TLS-Protect-Cloud/3-tlsp-certification-FAQs/","text":"Resources & FAQs \u00b6 Below are some useful resources and frequently asked questions from previous developers who've already completed the certification process: Resources \u00b6 Account Required Some of the resources on this page will require a Venafi user account in order to access. Please feel free to create one. If you encounter any issues, please let us know . TLS Protect Cloud API Documentation Example Solution Repo - This provides a thorough example of how the README.md file should be created to be most impactful for Venafi users. Rather than creating Word documents or PDFs, all documentation should start in Markdown, which provides better version control and can then be easily translated to other formats as needed. Venafi Marketplace - Explore the Marketplace to get an idea about some of the existing solutions to Venafi. FAQs \u00b6 Will my solution be listed on the Venafi Marketplace if I don't pursue official certification? ANSWER: Your solution may still be listed if it works with TLS Protect Datacenter , but it will not be listed as officially compatible with TLS Protect Cloud and will not have the official badge of certification. How long will the certification process take? ANSWER: The certification process itself moves relatively quickly - you've already done the time-consuming part building and documenting the solution. Once you've submitted a Request for Certification, it typically takes only a couple of days to schedule the final milestone demo (a short session for you to demonstrate the described functionality to the Venafi Ecosystem team). Will I receive any marketing assets that I can use on my own websites and collateral? ANSWER: Yes, definitely! We love seeing Venafi certification badges out in the wild. Official badges will be provided upon completion of the certification process. How often will I be required to re-certify my solution? ANSWER: For now, we'd like you to re-certify for any Major release or feature addition/enhancement. Minor releases don't require re-certification. If you've just released a new Major version or added a new feature, please submit a new certification request. Submit Certification Request","title":"Resources & FAQs"},{"location":"Developers/Certification/TLS-Protect-Cloud/3-tlsp-certification-FAQs/#resources-faqs","text":"Below are some useful resources and frequently asked questions from previous developers who've already completed the certification process:","title":"Resources & FAQs"},{"location":"Developers/Certification/TLS-Protect-Cloud/3-tlsp-certification-FAQs/#resources","text":"Account Required Some of the resources on this page will require a Venafi user account in order to access. Please feel free to create one. If you encounter any issues, please let us know . TLS Protect Cloud API Documentation Example Solution Repo - This provides a thorough example of how the README.md file should be created to be most impactful for Venafi users. Rather than creating Word documents or PDFs, all documentation should start in Markdown, which provides better version control and can then be easily translated to other formats as needed. Venafi Marketplace - Explore the Marketplace to get an idea about some of the existing solutions to Venafi.","title":"Resources"},{"location":"Developers/Certification/TLS-Protect-Cloud/3-tlsp-certification-FAQs/#faqs","text":"Will my solution be listed on the Venafi Marketplace if I don't pursue official certification? ANSWER: Your solution may still be listed if it works with TLS Protect Datacenter , but it will not be listed as officially compatible with TLS Protect Cloud and will not have the official badge of certification. How long will the certification process take? ANSWER: The certification process itself moves relatively quickly - you've already done the time-consuming part building and documenting the solution. Once you've submitted a Request for Certification, it typically takes only a couple of days to schedule the final milestone demo (a short session for you to demonstrate the described functionality to the Venafi Ecosystem team). Will I receive any marketing assets that I can use on my own websites and collateral? ANSWER: Yes, definitely! We love seeing Venafi certification badges out in the wild. Official badges will be provided upon completion of the certification process. How often will I be required to re-certify my solution? ANSWER: For now, we'd like you to re-certify for any Major release or feature addition/enhancement. Minor releases don't require re-certification. If you've just released a new Major version or added a new feature, please submit a new certification request. Submit Certification Request","title":"FAQs"},{"location":"Developers/Certification/TLS-Protect-Cloud/4-tlsp-certification-submit/","text":"Submit Your Solution \u00b6 Once your solution has been built and been tested internally by your team, you've produced any accompanying documentation and you've recorded a short video demo walking through each supported function of your solution, your solution is ready for certification! Submit Certification Request","title":"Submit Your Solution"},{"location":"Developers/Certification/TLS-Protect-Cloud/4-tlsp-certification-submit/#submit-your-solution","text":"Once your solution has been built and been tested internally by your team, you've produced any accompanying documentation and you've recorded a short video demo walking through each supported function of your solution, your solution is ready for certification! Submit Certification Request","title":"Submit Your Solution"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/","text":"Certification - TLS Protect For Kubernetes \u00b6 This page is meant to be your home base throughout the certification process, so please feel free to jump around, read ahead, bookmark and come back to it as needed. Ready to certify? If you've already completed your solution, understand and meet the necessary requirements and are ready to submit a request for Certification, you can start here. Introduction \u00b6 As a TLS Protect For Kubernetes Certified solution, Venafi users have an extra level of confidence that your solution was designed with their best interests at the forefront. For that reason, certified solutions see more adoption from our mutual users. When building a solution to TLS Protect For Kubernetes, one desired outcome should be official certification. Official certification is the first step to listing the solution on the Venafi Marketplace , which is the #1 way end users discover and deploy solutions. Certification is the only way that an solution will be listed on the Venafi Marketplace as compatible with TLS Protect For Kubernetes. The TLS Protect For Kubernetes Certification Program is still evolving and so some specifics about the following requirements are subject to change. Ample notice will be given to any developers of an existing certified solution, ensuring plenty of time to make any necessary updates to maintain certification. The following requirements are applicable to every TLS Protect For Kubernetes solution, however there may be additional, unlisted requirements depending on the specific use case of the solution. There will be solutions and use cases that come forward that are totally new and unique from every solution that has gone through the certification process - and that's GREAT! It means machine identity management is continuing to evolve and see continued adoption. We're all in this together In cases where the Venafi team requests additional requirements be met, we will work with you to determine what success looks like and do our best to provide any Tools/guidance necessary to reach certification. Technical Certification vs. Partner Program \u00b6 The technical certification process is not to be confused with Venafi Partnership, though the two are related. The best way to think about it would be \"Packaging\" vs. \"Marketing\". Packaging \u00b6 The final step of the TLS Protect For Kubernetes certification process will be Packaging - deciding how end users will deploy and interact with your solution. In order for end users to discover the solution and establish a strong user base, the packaging of the solution should be polished and easy to understand. Use of company logos, iconography, product names, marketing copy, etc. will all help users quickly identify your solution in the growing Venafi Marketplace . Marketing \u00b6 Marketing , on the other hand, focuses on bringing attention to a fully packaged & published solution. Once the solution has been certified and the initial Marketplace Listing has been created, the next logical step would be an official partnership with Venafi, which will also engage the Venafi Marketing team to start making some noise about the new solution available to Venafi users.","title":"TLS Protect For Kubernetes"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/#certification-tls-protect-for-kubernetes","text":"This page is meant to be your home base throughout the certification process, so please feel free to jump around, read ahead, bookmark and come back to it as needed. Ready to certify? If you've already completed your solution, understand and meet the necessary requirements and are ready to submit a request for Certification, you can start here.","title":"Certification - TLS Protect For Kubernetes"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/#introduction","text":"As a TLS Protect For Kubernetes Certified solution, Venafi users have an extra level of confidence that your solution was designed with their best interests at the forefront. For that reason, certified solutions see more adoption from our mutual users. When building a solution to TLS Protect For Kubernetes, one desired outcome should be official certification. Official certification is the first step to listing the solution on the Venafi Marketplace , which is the #1 way end users discover and deploy solutions. Certification is the only way that an solution will be listed on the Venafi Marketplace as compatible with TLS Protect For Kubernetes. The TLS Protect For Kubernetes Certification Program is still evolving and so some specifics about the following requirements are subject to change. Ample notice will be given to any developers of an existing certified solution, ensuring plenty of time to make any necessary updates to maintain certification. The following requirements are applicable to every TLS Protect For Kubernetes solution, however there may be additional, unlisted requirements depending on the specific use case of the solution. There will be solutions and use cases that come forward that are totally new and unique from every solution that has gone through the certification process - and that's GREAT! It means machine identity management is continuing to evolve and see continued adoption. We're all in this together In cases where the Venafi team requests additional requirements be met, we will work with you to determine what success looks like and do our best to provide any Tools/guidance necessary to reach certification.","title":"Introduction"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/#technical-certification-vs-partner-program","text":"The technical certification process is not to be confused with Venafi Partnership, though the two are related. The best way to think about it would be \"Packaging\" vs. \"Marketing\".","title":"Technical Certification vs. Partner Program"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/#packaging","text":"The final step of the TLS Protect For Kubernetes certification process will be Packaging - deciding how end users will deploy and interact with your solution. In order for end users to discover the solution and establish a strong user base, the packaging of the solution should be polished and easy to understand. Use of company logos, iconography, product names, marketing copy, etc. will all help users quickly identify your solution in the growing Venafi Marketplace .","title":"Packaging"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/#marketing","text":"Marketing , on the other hand, focuses on bringing attention to a fully packaged & published solution. Once the solution has been certified and the initial Marketplace Listing has been created, the next logical step would be an official partnership with Venafi, which will also engage the Venafi Marketing team to start making some noise about the new solution available to Venafi users.","title":"Marketing"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/2-tlspk-certification-reqs/","text":"Requirements \u00b6 There are currently two levels of certification for TLS Protect For Kubernetes solutions, Foundation Certification and Advanced Certification . It's our hope that every developer strives for the most comprehensive solution, but understand that isn't always possible due to resource and/or time constraints. The purpose of creating multiple levels of certification is two-fold: It provides a lower barrier to entry for smaller organizations and individual contributors It provides an opportunity for developers to further differentiate their solution by providing additional collateral that will help end users get started #fastsecure when using the solution. Meeting the requirements for Foundation Certification should be the first point of focus for any new developer. These requirements have been designed to create a simple pathway for developers to get a listing onto the Venafi Marketplace, while ensuring a consistent, stable experience for all TLS Protect For Kubernetes end users. All TLS Protect For Kubernetes solutions that are published on the Venafi Marketplace are required to meet the requirements for Foundation Certification. Advanced Certification provides a means to differentiate an solution that goes above & beyond the requirements specified above. Functionally, both Foundation Certification and Advanced Certification have the same technical requirements. The difference between the two levels is really about end user enablement and ongoing testing to ensure the solution remains fully functional. From an end user's perspective, generally the more collateral available to be consumed, the less likely end users are to have questions that might block them from testing and ultimately utilizing the solution. The easier it is to deploy and test the solution, the more widely adopted that solution becomes throughout the user base. More users generate more feedback and ideas, and the solution becomes more robust as a result. Certification Requirements \u00b6 Foundation Advanced The description of the solution is an accurate representation of functionality. The solution doesn't interfere with TLS Protect For Kubernetes native functionality or performance. The solution was developed with overall security best practices in mind and makes no attempts to harvest user data. The solution uses generally available interfaces to interact with TLS Protect For Kubernetes (jsctl, REST API, etc.). Accompanying documentation must be packaged with the solution and should include any necessary configuration instructions as well as clear usage examples. Templates are provided for this purpose. The support model is clearly defined for all user types. A demonstration of all documented functionality must be scheduled & completed with the Venafi Ecosystem team. Everything listed in the Foundation Certification Requirements section tab be completed, in addition to the following: A 5-10 minute technical demonstration video covering any initial configuration and typical usage examples must be available online. When necessary, and if possible/feasible for the solution, a test instance or account will be provided to the Venafi Ecosystem team for internal testing and demonstration purposes. Automated testing must be put in place to test all documented functionality of your solution. All REST endpoints and/or jsctl functions used by the solution must be documented and provided to Venafi. These will be used internally by Venafi to track which features & functions are being used most by developers and end users. They will not be shared publicly. Do you have feedback about the certification process? We've tried to make the certification process as simple and pain free as possible, but we're always looking to make it better. If you have any suggestions or feedback to improve the process, we'd love to hear them !","title":"Requirements"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/2-tlspk-certification-reqs/#requirements","text":"There are currently two levels of certification for TLS Protect For Kubernetes solutions, Foundation Certification and Advanced Certification . It's our hope that every developer strives for the most comprehensive solution, but understand that isn't always possible due to resource and/or time constraints. The purpose of creating multiple levels of certification is two-fold: It provides a lower barrier to entry for smaller organizations and individual contributors It provides an opportunity for developers to further differentiate their solution by providing additional collateral that will help end users get started #fastsecure when using the solution. Meeting the requirements for Foundation Certification should be the first point of focus for any new developer. These requirements have been designed to create a simple pathway for developers to get a listing onto the Venafi Marketplace, while ensuring a consistent, stable experience for all TLS Protect For Kubernetes end users. All TLS Protect For Kubernetes solutions that are published on the Venafi Marketplace are required to meet the requirements for Foundation Certification. Advanced Certification provides a means to differentiate an solution that goes above & beyond the requirements specified above. Functionally, both Foundation Certification and Advanced Certification have the same technical requirements. The difference between the two levels is really about end user enablement and ongoing testing to ensure the solution remains fully functional. From an end user's perspective, generally the more collateral available to be consumed, the less likely end users are to have questions that might block them from testing and ultimately utilizing the solution. The easier it is to deploy and test the solution, the more widely adopted that solution becomes throughout the user base. More users generate more feedback and ideas, and the solution becomes more robust as a result.","title":"Requirements"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/2-tlspk-certification-reqs/#certification-requirements","text":"Foundation Advanced The description of the solution is an accurate representation of functionality. The solution doesn't interfere with TLS Protect For Kubernetes native functionality or performance. The solution was developed with overall security best practices in mind and makes no attempts to harvest user data. The solution uses generally available interfaces to interact with TLS Protect For Kubernetes (jsctl, REST API, etc.). Accompanying documentation must be packaged with the solution and should include any necessary configuration instructions as well as clear usage examples. Templates are provided for this purpose. The support model is clearly defined for all user types. A demonstration of all documented functionality must be scheduled & completed with the Venafi Ecosystem team. Everything listed in the Foundation Certification Requirements section tab be completed, in addition to the following: A 5-10 minute technical demonstration video covering any initial configuration and typical usage examples must be available online. When necessary, and if possible/feasible for the solution, a test instance or account will be provided to the Venafi Ecosystem team for internal testing and demonstration purposes. Automated testing must be put in place to test all documented functionality of your solution. All REST endpoints and/or jsctl functions used by the solution must be documented and provided to Venafi. These will be used internally by Venafi to track which features & functions are being used most by developers and end users. They will not be shared publicly. Do you have feedback about the certification process? We've tried to make the certification process as simple and pain free as possible, but we're always looking to make it better. If you have any suggestions or feedback to improve the process, we'd love to hear them !","title":"Certification Requirements"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/3-tlspk-certification-FAQs/","text":"Resources & FAQs \u00b6 Below are some useful resources and frequently asked questions from previous developers who've already completed the certification process: Resources \u00b6 Example Solution Repo - This provides a thorough example of how the README.md file should be created to be most impactful for Venafi users. Rather than creating Word documents or PDFs, all documentation should start in Markdown, which provides better version control and can then be easily translated to other formats as needed. TLS Protect For Kubernetes API Documentation Venafi Marketplace - Explore the Marketplace to get an idea about some of the existing solutions to Venafi. FAQs \u00b6 Will my solution be listed on the Venafi Marketplace if I don't pursue official certification? ANSWER: Your solution may still be listed, but it will not be listed as officially compatible with TLS Protect For Kubernetes and will not have the official badge of certification. How long will the certification process take? ANSWER: The certification process itself moves relatively quickly - you've already done the time-consuming part building and documenting the solution. Once you've submitted a Request for Certification, it typically takes only a couple of days to schedule the final milestone demo (a short session for you to demonstrate the described functionality to the Venafi Ecosystem team). Will I receive any marketing assets that I can use on my own websites and collateral? ANSWER: Yes, definitely! We love seeing Venafi certification badges out in the wild. Official badges will be provided upon completion of the certification process. How often will I be required to re-certify my solution? ANSWER: For now, we'd like you to re-certify for any Major release or feature addition/enhancement. Minor releases don't require re-certification. If you've just released a new Major version or added a new feature, please submit a new certification request. Submit Certification Request","title":"Resources & FAQs"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/3-tlspk-certification-FAQs/#resources-faqs","text":"Below are some useful resources and frequently asked questions from previous developers who've already completed the certification process:","title":"Resources & FAQs"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/3-tlspk-certification-FAQs/#resources","text":"Example Solution Repo - This provides a thorough example of how the README.md file should be created to be most impactful for Venafi users. Rather than creating Word documents or PDFs, all documentation should start in Markdown, which provides better version control and can then be easily translated to other formats as needed. TLS Protect For Kubernetes API Documentation Venafi Marketplace - Explore the Marketplace to get an idea about some of the existing solutions to Venafi.","title":"Resources"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/3-tlspk-certification-FAQs/#faqs","text":"Will my solution be listed on the Venafi Marketplace if I don't pursue official certification? ANSWER: Your solution may still be listed, but it will not be listed as officially compatible with TLS Protect For Kubernetes and will not have the official badge of certification. How long will the certification process take? ANSWER: The certification process itself moves relatively quickly - you've already done the time-consuming part building and documenting the solution. Once you've submitted a Request for Certification, it typically takes only a couple of days to schedule the final milestone demo (a short session for you to demonstrate the described functionality to the Venafi Ecosystem team). Will I receive any marketing assets that I can use on my own websites and collateral? ANSWER: Yes, definitely! We love seeing Venafi certification badges out in the wild. Official badges will be provided upon completion of the certification process. How often will I be required to re-certify my solution? ANSWER: For now, we'd like you to re-certify for any Major release or feature addition/enhancement. Minor releases don't require re-certification. If you've just released a new Major version or added a new feature, please submit a new certification request. Submit Certification Request","title":"FAQs"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/4-tlspk-certification-submit/","text":"Submit Your Solution \u00b6 Once your solution has been built and been tested internally by your team, you've produced any accompanying documentation and you've recorded a short video demo walking through each supported function of your solution, your solution is ready for certification! Submit Certification Request","title":"Submit Your Solution"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/4-tlspk-certification-submit/#submit-your-solution","text":"Once your solution has been built and been tested internally by your team, you've produced any accompanying documentation and you've recorded a short video demo walking through each supported function of your solution, your solution is ready for certification! Submit Certification Request","title":"Submit Your Solution"},{"location":"Developers/Design-Patterns/general-guidelines/","text":"General Guidelines & Best Practices \u00b6 The following guidelines apply generically to all solutions to Venafi, regardless of solution type, and should be referenced as the solution is developed & tested, and as new features or enhancements are added. Naming Conventions \u00b6 A standard naming convention should be adopted to avoid any collisions when objects (applications, certificates, devices, etc.) are created. Collisions can occur when the name you define already exists in Venafi. You can use the same prefix or suffix, and then add something unique to the name. Debug Logging \u00b6 It's strongly encouraged to build in debug logging that can be enabled by end users when troubleshooting issues in their environments.","title":"Design Patterns"},{"location":"Developers/Design-Patterns/general-guidelines/#general-guidelines-best-practices","text":"The following guidelines apply generically to all solutions to Venafi, regardless of solution type, and should be referenced as the solution is developed & tested, and as new features or enhancements are added.","title":"General Guidelines & Best Practices"},{"location":"Developers/Design-Patterns/general-guidelines/#naming-conventions","text":"A standard naming convention should be adopted to avoid any collisions when objects (applications, certificates, devices, etc.) are created. Collisions can occur when the name you define already exists in Venafi. You can use the same prefix or suffix, and then add something unique to the name.","title":"Naming Conventions"},{"location":"Developers/Design-Patterns/general-guidelines/#debug-logging","text":"It's strongly encouraged to build in debug logging that can be enabled by end users when troubleshooting issues in their environments.","title":"Debug Logging"},{"location":"Developers/Design-Patterns/Cloud-WAF/0-intro-cloud-waf/","text":"Cloud WAF \u00b6 This page has moved! Design patterns for TLS Protect have been moved to Venafi Dev Central. Please visit the Cloud WAF page on Dev Central for the latest information.","title":"Cloud WAF"},{"location":"Developers/Design-Patterns/Cloud-WAF/0-intro-cloud-waf/#cloud-waf","text":"This page has moved! Design patterns for TLS Protect have been moved to Venafi Dev Central. Please visit the Cloud WAF page on Dev Central for the latest information.","title":"Cloud WAF"},{"location":"Developers/Design-Patterns/Ingress/0-intro-ingress/","text":"Ingress \u00b6 Ingress is the term used for a native Kubernetes resource that details the external routes into a cluster. Ingress may provide load balancing, TLS termination, intelligent routing and API Gateway functionality. cert-manager integrates with Ingress objects to fulfill their role in securing your Kubernetes clusters. TLS Protect For Kubernetes, which provides first-class support for Ingress objects, includes an enterprise-hardened version of cert-manager and capabilities to support machine identities in the enterprise. Introduction \u00b6 Kubernetes is a platform for building platforms which helps companies modernize with speed and agility . It has a reduced set of opinions about how business demands are fulfilled. This creates technological voids which the Kuberenetes community strives to fill. One such area is Ingress Controllers , for which the community has provided many options . Design Pattern: Ingress The principal concern of any ingress controller is to accept traffic from outside a given network space and intelligently pass that traffic on to an internally defined resource. This design pattern focuses on the use case of securely leveraging machine identities for use via ingress controllers. It highlights the need for automation to ensure that once your solution is deployed it stays there, proactively securing workloads long into the future. Before you begin, it's important to understand the \"what\" and \"why\" of Ingress . What is it? \u00b6 Ingress is a native Kubernetes construct. Objects of this type represent lines of communication from outside a cluster (which could mean the internet) to workloads running inside this cluster. Ingress objects bring network intelligence to multi-purpose proxy servers in the form of routing rules. Without the ability to span this divide Kubernetes would be isolated from the outside world and limited to running non-interactive workloads such as batch jobs. Whilst Ingress is native to Kubernetes, Ingress Controllers are not. An Ingress object can exist, but without an associated controller to respond, it will remain dormant - somewhat like a car without a driver. Selecting a suitable Ingress Controller is a choice each cluster intends for you to make. Why is it necessary? \u00b6 In addition to routing rules, Ingress Controllers also provide enhanced security which, given the importance of machine identities, should be your primary concern. The internet was originally envisioned as a medium for sharing information, however the modern world demands that information should be much better protected. To meet these demands we have seen the steady rise of HTTPS to the point where modern browsers baulk at the use of plain old HTTP so Transport Layer Security (TLS), which enables HTTPS, is now a mandatory requirement. Henceforth you need to enforce the security of your data in transit . Doing so with an Ingress Controller moves TLS termination closer to your workloads thereby helping to prevent misuse and compromise . Organizations use machine identities to provide end-to-end security of data sent between running processes with the TLS cryptographic protocol. The use of X.509 certificates and HTTPS are the most common manifestation of this. Those machine identities are sometimes installed at the application endpoint - as a layer of configuration inside your container images. Cloud native principles such as 12 factor dependencies may convince you this is the right choice. It's certainly convenient but this approach has a major flaw in that machine identities eventually expire so they must not be treated as static dependencies of your workloads . This matters because when active machine identities expire or become unavailable, outages happen. Outages Workloads can become unavailable for many reasons and any such event can be described as an outage . When you choose to secure your workloads , you introduce an additional failure point, specifically the machine identity itself. This is because machine identities are designed to expire after some predefined duration. When machine identities expire they stop working and the workloads they protect become unavailable. A likely outcome of failing to mitigate against outages is negative impact to brand reputation and lost revenue. Automation using the Machine Identity Management Control Plane is a key defense against outages. There are further limitations that stem from the use of containers with pre-baked security measures but the example above represents one that can be effectively tackled through the use of an Ingress. FAQs \u00b6 Before you proceed there may be a few initial questions that need addressing, for example: \"What problem will you solve?\" TLS Protect For Kubernetes users need machine identities that are trusted not just between workloads located on a single cluster using mTLS but also between public-facing workloads and other external clients such as end-user browsers. \"What will the outcome be?\" Users of your public-facing solution can stop outages caused by expiring machine identities. This builds customer trust and loyalty. \"What will you need to deliver?\" You solution will be in the form of Kubernetes controllers and CRDs . Your images will be sourced from a public container registry and installation will be achieved via a Helm chart. \"How will your solution be used?\" Automation via your Ingress controller will be initiated through the use of routes encoded within native Kubernetes Ingress objects. There may be a requirement for supplementary CRDs to configure your controller. \"What about authentication and authorization?\" Whilst it is not a requirement for your solution to handle authentication and authorization, there are Ingress controllers out there which do. If you choose this to provide this, we recommend you integrate with existing OpenID Connect (OIDC) identity providers such as Okta and Ping Identity . \"Why will you want to certify your solution?\" Hop over to our certification section for TLS Protect For Kubernetes to find out more If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.","title":"Ingress"},{"location":"Developers/Design-Patterns/Ingress/0-intro-ingress/#ingress","text":"Ingress is the term used for a native Kubernetes resource that details the external routes into a cluster. Ingress may provide load balancing, TLS termination, intelligent routing and API Gateway functionality. cert-manager integrates with Ingress objects to fulfill their role in securing your Kubernetes clusters. TLS Protect For Kubernetes, which provides first-class support for Ingress objects, includes an enterprise-hardened version of cert-manager and capabilities to support machine identities in the enterprise.","title":"Ingress"},{"location":"Developers/Design-Patterns/Ingress/0-intro-ingress/#introduction","text":"Kubernetes is a platform for building platforms which helps companies modernize with speed and agility . It has a reduced set of opinions about how business demands are fulfilled. This creates technological voids which the Kuberenetes community strives to fill. One such area is Ingress Controllers , for which the community has provided many options . Design Pattern: Ingress The principal concern of any ingress controller is to accept traffic from outside a given network space and intelligently pass that traffic on to an internally defined resource. This design pattern focuses on the use case of securely leveraging machine identities for use via ingress controllers. It highlights the need for automation to ensure that once your solution is deployed it stays there, proactively securing workloads long into the future. Before you begin, it's important to understand the \"what\" and \"why\" of Ingress .","title":"Introduction"},{"location":"Developers/Design-Patterns/Ingress/0-intro-ingress/#what-is-it","text":"Ingress is a native Kubernetes construct. Objects of this type represent lines of communication from outside a cluster (which could mean the internet) to workloads running inside this cluster. Ingress objects bring network intelligence to multi-purpose proxy servers in the form of routing rules. Without the ability to span this divide Kubernetes would be isolated from the outside world and limited to running non-interactive workloads such as batch jobs. Whilst Ingress is native to Kubernetes, Ingress Controllers are not. An Ingress object can exist, but without an associated controller to respond, it will remain dormant - somewhat like a car without a driver. Selecting a suitable Ingress Controller is a choice each cluster intends for you to make.","title":"What is it?"},{"location":"Developers/Design-Patterns/Ingress/0-intro-ingress/#why-is-it-necessary","text":"In addition to routing rules, Ingress Controllers also provide enhanced security which, given the importance of machine identities, should be your primary concern. The internet was originally envisioned as a medium for sharing information, however the modern world demands that information should be much better protected. To meet these demands we have seen the steady rise of HTTPS to the point where modern browsers baulk at the use of plain old HTTP so Transport Layer Security (TLS), which enables HTTPS, is now a mandatory requirement. Henceforth you need to enforce the security of your data in transit . Doing so with an Ingress Controller moves TLS termination closer to your workloads thereby helping to prevent misuse and compromise . Organizations use machine identities to provide end-to-end security of data sent between running processes with the TLS cryptographic protocol. The use of X.509 certificates and HTTPS are the most common manifestation of this. Those machine identities are sometimes installed at the application endpoint - as a layer of configuration inside your container images. Cloud native principles such as 12 factor dependencies may convince you this is the right choice. It's certainly convenient but this approach has a major flaw in that machine identities eventually expire so they must not be treated as static dependencies of your workloads . This matters because when active machine identities expire or become unavailable, outages happen. Outages Workloads can become unavailable for many reasons and any such event can be described as an outage . When you choose to secure your workloads , you introduce an additional failure point, specifically the machine identity itself. This is because machine identities are designed to expire after some predefined duration. When machine identities expire they stop working and the workloads they protect become unavailable. A likely outcome of failing to mitigate against outages is negative impact to brand reputation and lost revenue. Automation using the Machine Identity Management Control Plane is a key defense against outages. There are further limitations that stem from the use of containers with pre-baked security measures but the example above represents one that can be effectively tackled through the use of an Ingress.","title":"Why is it necessary?"},{"location":"Developers/Design-Patterns/Ingress/0-intro-ingress/#faqs","text":"Before you proceed there may be a few initial questions that need addressing, for example: \"What problem will you solve?\" TLS Protect For Kubernetes users need machine identities that are trusted not just between workloads located on a single cluster using mTLS but also between public-facing workloads and other external clients such as end-user browsers. \"What will the outcome be?\" Users of your public-facing solution can stop outages caused by expiring machine identities. This builds customer trust and loyalty. \"What will you need to deliver?\" You solution will be in the form of Kubernetes controllers and CRDs . Your images will be sourced from a public container registry and installation will be achieved via a Helm chart. \"How will your solution be used?\" Automation via your Ingress controller will be initiated through the use of routes encoded within native Kubernetes Ingress objects. There may be a requirement for supplementary CRDs to configure your controller. \"What about authentication and authorization?\" Whilst it is not a requirement for your solution to handle authentication and authorization, there are Ingress controllers out there which do. If you choose this to provide this, we recommend you integrate with existing OpenID Connect (OIDC) identity providers such as Okta and Ping Identity . \"Why will you want to certify your solution?\" Hop over to our certification section for TLS Protect For Kubernetes to find out more If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.","title":"FAQs"},{"location":"Developers/Design-Patterns/Ingress/1-requirements-ingress/","text":"Requirements and Considerations \u00b6 When developing Ingress solutions for the Machine Identity Management Control Plane , you should always build with the goal of certification in mind. TLS Protect For Kubernetes Certification Certified solutions see increased adoption from users. Find out more! Minimum Requirements \u00b6 The solution must automate the delivery/consumption of any machine identity required to enforce the security of workloads protected by the Ingress Controller . The solution must cope with both the creation and renewal of machine identities. The solution must perform any necessary updates or reconfigurations to bindings/associations attached to the machine identity . The solution must source its machine identities from Kubernetes secrets. Some clarifying remarks on the final point. The use of TLS secrets is commonplace for persisting X.509 certificates but organizations have been known to restrict or even prohibit their use. The Ingress specification mandates the use of secrets when you wish to entrust your Ingress Controller with the task of TLS termination. If this conflicts with your internal policies then the use of Ingress for TLS termination is not an option and you should consider something like the cert-manager csi-driver . The csi-driver solution, which is commonly used to enforce mTLS between workloads , eliminates the use of secrets and necessitates TLS termination closer to your workloads . Focus on UX The best solutions will require little, if any, human interaction after initial configuration. Security Considerations \u00b6 The Kubernetes Ingress specification provides for TLS enforcement on a per routing rule basis, but this security feature is optional . This is somewhat regrettable in light of the modern browser security requirements and your pursuit of zero-trust by default. Security should be uppermost among your concerns. As the developer of a Ingress Controller solution, you will need to: support only Ingress rules with explicit provision for TLS (by default). provide full support for modern OpenID Connect Identity Providers (e.g. Auth0, GitHub, Google, Okta, etc.) These considerations are in addition to any policy enforcement (e.g. minimum cipher strength) applied by TLSPK's approver-policy-enterprise , the Venafi TLS Protect products or upstream Certificate Authorities. Building a Better User Experience \u00b6 The user experience should be as painless as possible and the expectation is that your target product should: Be easy to install, preferably via Helm Be highly available Enable the user to deploy an MVP into your cluster with little or no configuration requirements Provide comprehensive logs for diagnostic purposes Export metrics in the common Prometheus format (e.g. network traffic, latency, error rates, utilization, request counts) Provide complete/appropriate documentation, both online and within CRDs when applicable Conforming to the these requirements will greatly enhance the user experience, providing additional value to teams and organizations. Success Stories \u00b6 Existing solutions that fit within this pattern: Venafi Marketplace Elsewhere NGINX Ingress Pomerium Ingress Kubernetes community","title":"Requirements and Considerations"},{"location":"Developers/Design-Patterns/Ingress/1-requirements-ingress/#requirements-and-considerations","text":"When developing Ingress solutions for the Machine Identity Management Control Plane , you should always build with the goal of certification in mind. TLS Protect For Kubernetes Certification Certified solutions see increased adoption from users. Find out more!","title":"Requirements and Considerations"},{"location":"Developers/Design-Patterns/Ingress/1-requirements-ingress/#minimum-requirements","text":"The solution must automate the delivery/consumption of any machine identity required to enforce the security of workloads protected by the Ingress Controller . The solution must cope with both the creation and renewal of machine identities. The solution must perform any necessary updates or reconfigurations to bindings/associations attached to the machine identity . The solution must source its machine identities from Kubernetes secrets. Some clarifying remarks on the final point. The use of TLS secrets is commonplace for persisting X.509 certificates but organizations have been known to restrict or even prohibit their use. The Ingress specification mandates the use of secrets when you wish to entrust your Ingress Controller with the task of TLS termination. If this conflicts with your internal policies then the use of Ingress for TLS termination is not an option and you should consider something like the cert-manager csi-driver . The csi-driver solution, which is commonly used to enforce mTLS between workloads , eliminates the use of secrets and necessitates TLS termination closer to your workloads . Focus on UX The best solutions will require little, if any, human interaction after initial configuration.","title":"Minimum Requirements"},{"location":"Developers/Design-Patterns/Ingress/1-requirements-ingress/#security-considerations","text":"The Kubernetes Ingress specification provides for TLS enforcement on a per routing rule basis, but this security feature is optional . This is somewhat regrettable in light of the modern browser security requirements and your pursuit of zero-trust by default. Security should be uppermost among your concerns. As the developer of a Ingress Controller solution, you will need to: support only Ingress rules with explicit provision for TLS (by default). provide full support for modern OpenID Connect Identity Providers (e.g. Auth0, GitHub, Google, Okta, etc.) These considerations are in addition to any policy enforcement (e.g. minimum cipher strength) applied by TLSPK's approver-policy-enterprise , the Venafi TLS Protect products or upstream Certificate Authorities.","title":"Security Considerations"},{"location":"Developers/Design-Patterns/Ingress/1-requirements-ingress/#building-a-better-user-experience","text":"The user experience should be as painless as possible and the expectation is that your target product should: Be easy to install, preferably via Helm Be highly available Enable the user to deploy an MVP into your cluster with little or no configuration requirements Provide comprehensive logs for diagnostic purposes Export metrics in the common Prometheus format (e.g. network traffic, latency, error rates, utilization, request counts) Provide complete/appropriate documentation, both online and within CRDs when applicable Conforming to the these requirements will greatly enhance the user experience, providing additional value to teams and organizations.","title":"Building a Better User Experience"},{"location":"Developers/Design-Patterns/Ingress/1-requirements-ingress/#success-stories","text":"Existing solutions that fit within this pattern: Venafi Marketplace Elsewhere NGINX Ingress Pomerium Ingress Kubernetes community","title":"Success Stories"},{"location":"Developers/Design-Patterns/Ingress/2-getting-started-ingress/","text":"Getting Started \u00b6 If you've made it here, you should already have a general understanding about how the Ingress resource relates to machine identities and you're ready to get started developing your Ingress solution. High-level Process \u00b6 Head over to TLS Protect For Kubernetes and select ACCESS YOUR ACCOUNT . Log In to your account or , if you don't already have one, select Sign Up , complete the Terms of Service and follow the on screen prompts. Note : new users will be allocated a organization name made of two randomly selected words (e.g. foxtrot-charlie) which is your private workspace within the SaaS platform. From the TLS Protect For Kubernetes console, select Clusters and CONNECT NEW CLUSTER to familiarize yourself with the steps required to introduce a Kubernetes cluster to your organization. Your choice of Kubernetes distribution is somewhat arbitrary, however you should consider the need to create them repeatedly to enable thorough testing. You should also consider that not all distributions provide native support for Kubernetes services of type LoadBalancer. Try out one or two of the most popular Ingress Controllers to familiarize yourself with their shared behavior and relative strengths. Head over to https://platform.jetstack.io/org/[ORG]/certinventory/cluster/[CLUSTER]/ingresses . This is where you will locate any active Ingress objects in your registered cluster(s). Start building! We highly recommend using Kubebuilder framework to increase your velocity and reduce the complexity inherent in developing any Kubernetes controller. Perform functional testing . Get certified ! Getting Help \u00b6 We think you'll find the following references helpful when developing your solution. Official Kubernetes Ingress Documentation Kubernetes Ingress Explained for Beginners Everything you need to know about Kubebuilder Writing a Kubernetes Operator from Scratch Using Kubebuilder If you are not able to find what you're looking for or you've found other articles/tools that deserve to be included here please post a question to the Developer Forum section of Venafi's Warrior Community or email the Ecosystem team.","title":"Getting Started"},{"location":"Developers/Design-Patterns/Ingress/2-getting-started-ingress/#getting-started","text":"If you've made it here, you should already have a general understanding about how the Ingress resource relates to machine identities and you're ready to get started developing your Ingress solution.","title":"Getting Started"},{"location":"Developers/Design-Patterns/Ingress/2-getting-started-ingress/#high-level-process","text":"Head over to TLS Protect For Kubernetes and select ACCESS YOUR ACCOUNT . Log In to your account or , if you don't already have one, select Sign Up , complete the Terms of Service and follow the on screen prompts. Note : new users will be allocated a organization name made of two randomly selected words (e.g. foxtrot-charlie) which is your private workspace within the SaaS platform. From the TLS Protect For Kubernetes console, select Clusters and CONNECT NEW CLUSTER to familiarize yourself with the steps required to introduce a Kubernetes cluster to your organization. Your choice of Kubernetes distribution is somewhat arbitrary, however you should consider the need to create them repeatedly to enable thorough testing. You should also consider that not all distributions provide native support for Kubernetes services of type LoadBalancer. Try out one or two of the most popular Ingress Controllers to familiarize yourself with their shared behavior and relative strengths. Head over to https://platform.jetstack.io/org/[ORG]/certinventory/cluster/[CLUSTER]/ingresses . This is where you will locate any active Ingress objects in your registered cluster(s). Start building! We highly recommend using Kubebuilder framework to increase your velocity and reduce the complexity inherent in developing any Kubernetes controller. Perform functional testing . Get certified !","title":"High-level Process"},{"location":"Developers/Design-Patterns/Ingress/2-getting-started-ingress/#getting-help","text":"We think you'll find the following references helpful when developing your solution. Official Kubernetes Ingress Documentation Kubernetes Ingress Explained for Beginners Everything you need to know about Kubebuilder Writing a Kubernetes Operator from Scratch Using Kubebuilder If you are not able to find what you're looking for or you've found other articles/tools that deserve to be included here please post a question to the Developer Forum section of Venafi's Warrior Community or email the Ecosystem team.","title":"Getting Help"},{"location":"Developers/Design-Patterns/Ingress/3-functional-testing-ingress/","text":"Functional Testing \u00b6 During development of your Ingress solution, you should keep the following functional tests in mind for this design pattern. The test cases listed below are directly related to the requirements and considerations outlined for this use case. What is functional testing? To summarize Wikipedia : Functional testing is a QA process that sees a \"tester\" run through all documented functionality of a product or, in this case, an integrated solution. It's a great way to uncover bugs, unexpected behaviors and documentation errors. The functional tests documented below are provided as examples. Depending on the supported functionality of the target platform/service you're building for and/or the complexity of your solution, some tests listed below may not be necessary. Similarly, it's possible that you've got such a new or unique solution, that we haven't identified recommended functional tests yet. If you've got suggestions and/or functional tests that helped during your development, please let us know ! Reduce Confirmation Bias It can be extremely helpful, especially when writing documentation that accompanies your solution, to involve others on your team who haven't been involved in the development process. While you might be able to perform all functionality without even referencing the docs, it's possible that a fresh set of eyes will uncover typos or minor omissions that someone directly involved in development might miss. Basic Functionality Tests \u00b6 The following functionality tests should be applicable to every solution targeting this use case. Test Case Description Desired Outcome ING-01 Documentation : Solution should be fully documented Both online and embedded CRD documentation (when applicable) is provided ING-02 Error Handling : Perform an operation which you expect to fail (unsupported key size, missing/incomplete data, etc.) The error will be encountered and a meaningful error message will be presented to the end user and, if applicable, back to Venafi ING-03 CRUD Lifecycle : Standard logic around creation, modification and deletion Ingress and its standard behavioral effects should be observable from within TLS Protect For Kubernetes. Ingress is observed as both updated and subsequently deleted. Exceptions to these outcomes must be justified and documented ING-04 TLS : Support TLS-enabled public routes TLS-enabled Ingress routes are provisioned and observable from within TLS Protect For Kubernetes. Meanwhile, browser can navigate to workload via HTTPS without security warnings ING-05 Certificate Renewed : Renew certificate used as a machine identity Revised expiry date for Ingress machine identity is visible from within TLS Protect For Kubernetes. Ingress reconfiguration is automatically triggered Advanced Functionality Tests \u00b6 Depending on the exact functionality of the target solution, the following tests may or may not be applicable. Test Case Description Desired Outcome ING-101 OpenID Connect : Integrate with OpenID Connect identity providers Alongside machine identities security, your solution should also be able to demonstrate support for Authentication and Authorization","title":"Functional Testing"},{"location":"Developers/Design-Patterns/Ingress/3-functional-testing-ingress/#functional-testing","text":"During development of your Ingress solution, you should keep the following functional tests in mind for this design pattern. The test cases listed below are directly related to the requirements and considerations outlined for this use case. What is functional testing? To summarize Wikipedia : Functional testing is a QA process that sees a \"tester\" run through all documented functionality of a product or, in this case, an integrated solution. It's a great way to uncover bugs, unexpected behaviors and documentation errors. The functional tests documented below are provided as examples. Depending on the supported functionality of the target platform/service you're building for and/or the complexity of your solution, some tests listed below may not be necessary. Similarly, it's possible that you've got such a new or unique solution, that we haven't identified recommended functional tests yet. If you've got suggestions and/or functional tests that helped during your development, please let us know ! Reduce Confirmation Bias It can be extremely helpful, especially when writing documentation that accompanies your solution, to involve others on your team who haven't been involved in the development process. While you might be able to perform all functionality without even referencing the docs, it's possible that a fresh set of eyes will uncover typos or minor omissions that someone directly involved in development might miss.","title":"Functional Testing"},{"location":"Developers/Design-Patterns/Ingress/3-functional-testing-ingress/#basic-functionality-tests","text":"The following functionality tests should be applicable to every solution targeting this use case.","title":"Basic Functionality Tests"},{"location":"Developers/Design-Patterns/Ingress/3-functional-testing-ingress/#advanced-functionality-tests","text":"Depending on the exact functionality of the target solution, the following tests may or may not be applicable.","title":"Advanced Functionality Tests"},{"location":"Developers/Design-Patterns/Issuer/0-intro-issuer/","text":"Issuer \u00b6 Issuer is a capability of cert-manager enabling integration with machine identity providers. These providers are typically Certificate Authorities which publish digital certificates to secure communication between workloads . cert-manager is a critical component in the fight to secure your Kubernetes clusters, helping companies modernize with speed and agility . TLS Protect For Kubernetes includes an enterprise-hardened version of cert-manager alongside extensions to support and manage machine identities in the enterprise. Introduction \u00b6 The chapter on Ingress explains how Kubernetes is broadly unopinionated about the tools you use to fulfill your business demands, such as how you ensure the security of your workloads . The CNCF's move to accept cert-manager as an incubating project solidifies its reputation as the de-facto Kubernetes solution for stopping outages caused by TLS certificate expiry. Design Pattern: Issuer This design pattern focuses on the development of bespoke Issuers for cert-manager. The principal concern of any Issuer is to supervise the creation and renewal of machine identities. This pattern highlights the need to automate everywhere , ensuring that once your solution is deployed it remains in place, proactively securing workloads long into the future. Before you begin, it's important to understand the \"what\" and \"why\" of Issuers in the context of Kubernetes. What is it? \u00b6 The Issuer capability in cert-manager extends the Kubernetes API, abstracting away the complexity of machine identity providers inside your clusters. Each Issuer object represents a provider capable of signing and issuing machine identities, typically in the form of X.509 certificates. These providers could be digital security companies you already know and trust, non-profit organizations or just some well-known devices inside your data center. Each provider brings its own strengths and consumer adoption is determined by various factor such as organizational policy, existing infrastructure, business relationships, individual choice and the task at hand. In a Kubernetes architecture which prevents misuse and compromise , use of a cert-manager Issuer is a mandatory requirement. Why is it necessary? \u00b6 The following diagram is taken from the cert-manager documentation homepage . Native Issuer support in cert-manager is currently limited to the machine identity providers shown above. As a developer who needs to extend the reach of cert-manager to provide support for an alternate machine identity provider, this design pattern is for you. FAQs \u00b6 Before you proceed there may be a few initial questions that need addressing, for example: \"What problem will you solve?\" TLS Protect For Kubernetes users need to provide their clusters with a robust mechanism for delivery of machine identities from your CA's. \"What will the outcome be?\" Automated delivery of machine identities from your CA to your Kubernetes clusters and a reduction in outages due to certificate expiry. \"What will you need to deliver?\" You solution will be in the form of Kubernetes controllers and CRDs . Your images will be sourced from a public container registry and installation will be achieved via a Helm chart. \"How will your solution be used?\" Automation via your issuer will be initiated through the use of declarative references inside cert-manager objects. \"What about authentication and authorization?\" From the perspective of cert-manager there will be zero authentication and authorization requirements, but it will likely be a different story from the perspective of your machine identity provider. You may choose to consult with your machine identity provider to ensure that their own best practices are adhered to. \"Why will you want to certify your solution?\" Hop over to our certification section for TLS Protect For Kubernetes to find out more If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.","title":"Issuer"},{"location":"Developers/Design-Patterns/Issuer/0-intro-issuer/#issuer","text":"Issuer is a capability of cert-manager enabling integration with machine identity providers. These providers are typically Certificate Authorities which publish digital certificates to secure communication between workloads . cert-manager is a critical component in the fight to secure your Kubernetes clusters, helping companies modernize with speed and agility . TLS Protect For Kubernetes includes an enterprise-hardened version of cert-manager alongside extensions to support and manage machine identities in the enterprise.","title":"Issuer"},{"location":"Developers/Design-Patterns/Issuer/0-intro-issuer/#introduction","text":"The chapter on Ingress explains how Kubernetes is broadly unopinionated about the tools you use to fulfill your business demands, such as how you ensure the security of your workloads . The CNCF's move to accept cert-manager as an incubating project solidifies its reputation as the de-facto Kubernetes solution for stopping outages caused by TLS certificate expiry. Design Pattern: Issuer This design pattern focuses on the development of bespoke Issuers for cert-manager. The principal concern of any Issuer is to supervise the creation and renewal of machine identities. This pattern highlights the need to automate everywhere , ensuring that once your solution is deployed it remains in place, proactively securing workloads long into the future. Before you begin, it's important to understand the \"what\" and \"why\" of Issuers in the context of Kubernetes.","title":"Introduction"},{"location":"Developers/Design-Patterns/Issuer/0-intro-issuer/#what-is-it","text":"The Issuer capability in cert-manager extends the Kubernetes API, abstracting away the complexity of machine identity providers inside your clusters. Each Issuer object represents a provider capable of signing and issuing machine identities, typically in the form of X.509 certificates. These providers could be digital security companies you already know and trust, non-profit organizations or just some well-known devices inside your data center. Each provider brings its own strengths and consumer adoption is determined by various factor such as organizational policy, existing infrastructure, business relationships, individual choice and the task at hand. In a Kubernetes architecture which prevents misuse and compromise , use of a cert-manager Issuer is a mandatory requirement.","title":"What is it?"},{"location":"Developers/Design-Patterns/Issuer/0-intro-issuer/#why-is-it-necessary","text":"The following diagram is taken from the cert-manager documentation homepage . Native Issuer support in cert-manager is currently limited to the machine identity providers shown above. As a developer who needs to extend the reach of cert-manager to provide support for an alternate machine identity provider, this design pattern is for you.","title":"Why is it necessary?"},{"location":"Developers/Design-Patterns/Issuer/0-intro-issuer/#faqs","text":"Before you proceed there may be a few initial questions that need addressing, for example: \"What problem will you solve?\" TLS Protect For Kubernetes users need to provide their clusters with a robust mechanism for delivery of machine identities from your CA's. \"What will the outcome be?\" Automated delivery of machine identities from your CA to your Kubernetes clusters and a reduction in outages due to certificate expiry. \"What will you need to deliver?\" You solution will be in the form of Kubernetes controllers and CRDs . Your images will be sourced from a public container registry and installation will be achieved via a Helm chart. \"How will your solution be used?\" Automation via your issuer will be initiated through the use of declarative references inside cert-manager objects. \"What about authentication and authorization?\" From the perspective of cert-manager there will be zero authentication and authorization requirements, but it will likely be a different story from the perspective of your machine identity provider. You may choose to consult with your machine identity provider to ensure that their own best practices are adhered to. \"Why will you want to certify your solution?\" Hop over to our certification section for TLS Protect For Kubernetes to find out more If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.","title":"FAQs"},{"location":"Developers/Design-Patterns/Issuer/1-requirements-issuer/","text":"Requirements and Considerations \u00b6 When developing Issuer solutions for the Machine Identity Management Control Plane , you should always build with the goal of certification in mind. TLS Protect For Kubernetes Certification Certified solutions see increased adoption from users. Find out more! Minimum Requirements \u00b6 The solution must be open source and its container images published to publicly available image registries. The solution must automate the production of machine identities from the underlying provider to enforce the security of traffic between workloads . The solution will expect cert-manager to hand CertificateRequest objects to it and be able to, directly or indirectly, produce a machine identity . Security Considerations \u00b6 The extent of your security considerations is somewhat governed by the intention of your Issuer. As the developer of an Issuer solution, you will need to determine if your underlying Certificate Authority (CA) could be required to secure internet traffic or not. Internal traffic could be deemed to be secure when plain-text communication is eliminated, which is easier to ensure. The requirements for securing internet traffic are likely higher, since your responsibility now extends to cover concerns such as identity and attestation (e.g. \"is this domain owner really who they say they are?\") To clarify, you would find it much easier to build a self-signed Issuer than an Issuer for something like a Certificate Authority where security concerns such as authentication would need to be addressed. Building a Better User Experience \u00b6 The user experience should be as painless as possible and the expectation is that your solution should be: Easy to install, preferably via Helm Able to deploy an MVP into your cluster with little or no configuration requirements Provide comprehensive logs and metrics for diagnostic purposes Provide complete/appropriate documentation online and via CRDs Conforming to the these requirements will greatly enhance the user experience, providing additional value to teams and organizations whilst paving the way to certification of your solution. Success Stories \u00b6 Existing solutions that fit within this pattern: Community Proprietary The cert-manager community provides a collection of open-source External Issuers enabling distribution of machine identities from providers including AWS, Google and Cloudflare. The venafi-enhanced-issuer is provided with TLS Protect For Kubernetes to meet the needs of enterprise customer.","title":"Requirements and Considerations"},{"location":"Developers/Design-Patterns/Issuer/1-requirements-issuer/#requirements-and-considerations","text":"When developing Issuer solutions for the Machine Identity Management Control Plane , you should always build with the goal of certification in mind. TLS Protect For Kubernetes Certification Certified solutions see increased adoption from users. Find out more!","title":"Requirements and Considerations"},{"location":"Developers/Design-Patterns/Issuer/1-requirements-issuer/#minimum-requirements","text":"The solution must be open source and its container images published to publicly available image registries. The solution must automate the production of machine identities from the underlying provider to enforce the security of traffic between workloads . The solution will expect cert-manager to hand CertificateRequest objects to it and be able to, directly or indirectly, produce a machine identity .","title":"Minimum Requirements"},{"location":"Developers/Design-Patterns/Issuer/1-requirements-issuer/#security-considerations","text":"The extent of your security considerations is somewhat governed by the intention of your Issuer. As the developer of an Issuer solution, you will need to determine if your underlying Certificate Authority (CA) could be required to secure internet traffic or not. Internal traffic could be deemed to be secure when plain-text communication is eliminated, which is easier to ensure. The requirements for securing internet traffic are likely higher, since your responsibility now extends to cover concerns such as identity and attestation (e.g. \"is this domain owner really who they say they are?\") To clarify, you would find it much easier to build a self-signed Issuer than an Issuer for something like a Certificate Authority where security concerns such as authentication would need to be addressed.","title":"Security Considerations"},{"location":"Developers/Design-Patterns/Issuer/1-requirements-issuer/#building-a-better-user-experience","text":"The user experience should be as painless as possible and the expectation is that your solution should be: Easy to install, preferably via Helm Able to deploy an MVP into your cluster with little or no configuration requirements Provide comprehensive logs and metrics for diagnostic purposes Provide complete/appropriate documentation online and via CRDs Conforming to the these requirements will greatly enhance the user experience, providing additional value to teams and organizations whilst paving the way to certification of your solution.","title":"Building a Better User Experience"},{"location":"Developers/Design-Patterns/Issuer/1-requirements-issuer/#success-stories","text":"Existing solutions that fit within this pattern: Community Proprietary The cert-manager community provides a collection of open-source External Issuers enabling distribution of machine identities from providers including AWS, Google and Cloudflare. The venafi-enhanced-issuer is provided with TLS Protect For Kubernetes to meet the needs of enterprise customer.","title":"Success Stories"},{"location":"Developers/Design-Patterns/Issuer/2-getting-started-issuer/","text":"Getting Started \u00b6 If you've made it here, you should already have a general understanding about Issuers and machine identities . Now you're ready to get started developing your Issuer solution. Steps \u00b6 Head over to TLS Protect For Kubernetes and select ACCESS YOUR ACCOUNT . Log In to your account or , if you don't already have one, select Sign Up , complete the Terms of Service and follow the on screen prompts. Note : new users will be allocated a organization name made of two randomly selected words (e.g. foxtrot-charlie) which is your private workspace within the SaaS platform. From the TLS Protect For Kubernetes console, select Clusters and CONNECT NEW CLUSTER to familiarize yourself with the steps required to introduce a Kubernetes cluster to your organization. Your choice of Kubernetes distribution is somewhat arbitrary, however you should consider the need to create them repeatedly to enable thorough testing. Head over to https://platform.jetstack.io/org/[ORG]/certinventory/cluster/[CLUSTER]/issuers . This is where you will locate any active Issuer objects in your registered cluster(s). From the TLS Protect For Kubernetes console, select ADD AN ISSUER to familiarize yourself with the steps required to introduce new Issuer objects (both native and external ) to your cluster. Start building! Use a public GitHub repository with Commit Signature Veficiation enabled. Use a CI/CD platform, such as Github Actions . Use Kubebuilder framework to increase your velocity and reduce the complexity inherent in developing any Kubernetes controller. Perform functional testing . Get certified ! Getting Help \u00b6 The cert-manager team have produced an article named Implementing External Issuers which is geared directly towards assisting developers like yourself. Pay special attention to the sections named Approval and Conditions . If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.","title":"Getting Started"},{"location":"Developers/Design-Patterns/Issuer/2-getting-started-issuer/#getting-started","text":"If you've made it here, you should already have a general understanding about Issuers and machine identities . Now you're ready to get started developing your Issuer solution.","title":"Getting Started"},{"location":"Developers/Design-Patterns/Issuer/2-getting-started-issuer/#steps","text":"Head over to TLS Protect For Kubernetes and select ACCESS YOUR ACCOUNT . Log In to your account or , if you don't already have one, select Sign Up , complete the Terms of Service and follow the on screen prompts. Note : new users will be allocated a organization name made of two randomly selected words (e.g. foxtrot-charlie) which is your private workspace within the SaaS platform. From the TLS Protect For Kubernetes console, select Clusters and CONNECT NEW CLUSTER to familiarize yourself with the steps required to introduce a Kubernetes cluster to your organization. Your choice of Kubernetes distribution is somewhat arbitrary, however you should consider the need to create them repeatedly to enable thorough testing. Head over to https://platform.jetstack.io/org/[ORG]/certinventory/cluster/[CLUSTER]/issuers . This is where you will locate any active Issuer objects in your registered cluster(s). From the TLS Protect For Kubernetes console, select ADD AN ISSUER to familiarize yourself with the steps required to introduce new Issuer objects (both native and external ) to your cluster. Start building! Use a public GitHub repository with Commit Signature Veficiation enabled. Use a CI/CD platform, such as Github Actions . Use Kubebuilder framework to increase your velocity and reduce the complexity inherent in developing any Kubernetes controller. Perform functional testing . Get certified !","title":"Steps"},{"location":"Developers/Design-Patterns/Issuer/2-getting-started-issuer/#getting-help","text":"The cert-manager team have produced an article named Implementing External Issuers which is geared directly towards assisting developers like yourself. Pay special attention to the sections named Approval and Conditions . If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.","title":"Getting Help"},{"location":"Developers/Design-Patterns/Issuer/3-functional-testing-issuer/","text":"Functional Testing \u00b6 During development of your Issuer solution, you should keep the following functional tests in mind for this design pattern. The test cases listed below are directly related to the requirements and considerations outlined for this use case. What is functional testing? To summarize Wikipedia : Functional testing is a QA process that sees a \"tester\" run through all documented functionality of a product or, in this case, an integrated solution. It's a great way to uncover bugs, unexpected behaviors and documentation errors. The functional tests documented below are provided as examples. Depending on the supported functionality of the target platform/service you're building for and/or the complexity of your solution, some tests listed below may not be necessary. Similarly, it's possible that you've got such a new or unique solution, that we haven't identified recommended functional tests yet. If you've got suggestions and/or functional tests that helped during your development, please let us know ! Reduce Confirmation Bias It can be extremely helpful, especially when writing documentation that accompanies your solution, to involve others on your team who haven't been involved in the development process. While you might be able to perform all functionality without even referencing the docs, it's possible that a fresh set of eyes will uncover typos or minor omissions that someone directly involved in development might miss. Basic Functionality Tests \u00b6 The following functionality tests should be applicable to every solution targeting this use case. Test Case Description Desired Outcome ISS-01 Documentation : Solution should be fully documented Both online and embedded CRD documentation (when applicable) is provided ISS-02 Error Handling : Perform an operation which you expect to fail (unsupported key size, missing/incomplete data, provider-centric policy violation, etc.) A meaningful error message will be recorded in the cert-manager logs and will propagate to the TLS Protect For Kubernetes front-end ISS-03 New Certificate : Provision a new certificate for use as a machine identity Certificate is delivered back to cert-manager and observably ready for use from within TLS Protect For Kubernetes ISS-04 Certificate Renewed : Renew certificate for use as a machine identity Certificate is delivered back to cert-manager and revised expiry date is visible from within TLS Protect For Kubernetes ISS-05 Approval Status : Without approval from the approver-policy component of TLS Protect For Kubernetes Enterprise, no certificate should be issued Unapproved certificates will be flagged as such in TLS Protect For Kubernetes ISS-06 Ingress Integration : Provide seamless integration with Ingress Controllers Ingresses enlisting the support of your Issuer solution will behave as per native Issuers with regard to machine identities Advanced Functionality Tests \u00b6 Depending on the exact functionality of the target solution, the following tests may or may not be applicable. Test Case Description Desired Outcome None","title":"Functional Testing"},{"location":"Developers/Design-Patterns/Issuer/3-functional-testing-issuer/#functional-testing","text":"During development of your Issuer solution, you should keep the following functional tests in mind for this design pattern. The test cases listed below are directly related to the requirements and considerations outlined for this use case. What is functional testing? To summarize Wikipedia : Functional testing is a QA process that sees a \"tester\" run through all documented functionality of a product or, in this case, an integrated solution. It's a great way to uncover bugs, unexpected behaviors and documentation errors. The functional tests documented below are provided as examples. Depending on the supported functionality of the target platform/service you're building for and/or the complexity of your solution, some tests listed below may not be necessary. Similarly, it's possible that you've got such a new or unique solution, that we haven't identified recommended functional tests yet. If you've got suggestions and/or functional tests that helped during your development, please let us know ! Reduce Confirmation Bias It can be extremely helpful, especially when writing documentation that accompanies your solution, to involve others on your team who haven't been involved in the development process. While you might be able to perform all functionality without even referencing the docs, it's possible that a fresh set of eyes will uncover typos or minor omissions that someone directly involved in development might miss.","title":"Functional Testing"},{"location":"Developers/Design-Patterns/Issuer/3-functional-testing-issuer/#basic-functionality-tests","text":"The following functionality tests should be applicable to every solution targeting this use case.","title":"Basic Functionality Tests"},{"location":"Developers/Design-Patterns/Issuer/3-functional-testing-issuer/#advanced-functionality-tests","text":"Depending on the exact functionality of the target solution, the following tests may or may not be applicable.","title":"Advanced Functionality Tests"},{"location":"Developers/Design-Patterns/Management-Layer/0-intro-management-layer/","text":"Management Layer \u00b6 This page has moved! Design patterns for TLS Protect have been moved to Venafi Dev Central. Please visit the Management Layer page on Dev Central for the latest information.","title":"Management Layer"},{"location":"Developers/Design-Patterns/Management-Layer/0-intro-management-layer/#management-layer","text":"This page has moved! Design patterns for TLS Protect have been moved to Venafi Dev Central. Please visit the Management Layer page on Dev Central for the latest information.","title":"Management Layer"},{"location":"Getting-Started/1-how-to-engage/","text":"Start Engaging with Venafi Ecosystem \u00b6 Venafi Ecosystem is the hub of innovation. It involves and relies on the participation of many different players including external Developers, customers, and Venafi internal stakeholders, all center around Machine Identity Management to safeguard world's machine identities. Venafi Ecosystem provides and maintains the infrastructure, tooling, support for the diverse set of players. Below are the different ways to engage with the Ecosystem depending on the role you play: Funded Developers Existing or Prospective Customers I want to build with Venafi","title":"How to Engage"},{"location":"Getting-Started/1-how-to-engage/#start-engaging-with-venafi-ecosystem","text":"Venafi Ecosystem is the hub of innovation. It involves and relies on the participation of many different players including external Developers, customers, and Venafi internal stakeholders, all center around Machine Identity Management to safeguard world's machine identities. Venafi Ecosystem provides and maintains the infrastructure, tooling, support for the diverse set of players. Below are the different ways to engage with the Ecosystem depending on the role you play: Funded Developers Existing or Prospective Customers I want to build with Venafi","title":"Start Engaging with Venafi Ecosystem"},{"location":"Getting-Started/customers/","text":"The most common use cases a Venafi customer has for Ecosystem can be captured in the flow graphs below. Use Case 1 : You need to know whether we already have an integration with a different technology. SDJS_Widget(\"A5C349CC4A4CF4C4017431177EDFA7B37D6\",87031,1,\"\"); Use Case 2 : You have a suggestion and a nice idea for an integration with a technology, please provide all the details necessary on Venafi ideas community channel. Don't forget to tag your account manager and solution architect. For any other issues, you can send us an issue report .","title":"For Existing or Prospective Customers"},{"location":"Getting-Started/funded-developers/","text":"Development Fund Program \u00b6 You can always review the details of the Development Fund Program . Milestones and Checkins \u00b6 A typical journey for a Developer funded by the program is organized by a series of milestones and actions. SDJS_Widget(\"9B655732E9F0B87CAE2F9687FDEDF6BCD81\",41500,1,\"\"); This journey is managed through our Ecosystem Management Platform. If you do not yet have access to the platform, send us a request . This process should be followed by most Developers who are funded through Venafi's Development Fund Program . In rare cases, exceptions have to be made. In which case, you will have milestones that are not part of the five outlined above. These milestone actions will be reflected in the above-mentioned platform. For any other issues, you can send us an issue report .","title":"For Funded Developers"},{"location":"Getting-Started/funded-developers/#development-fund-program","text":"You can always review the details of the Development Fund Program .","title":"Development Fund Program"},{"location":"Getting-Started/funded-developers/#milestones-and-checkins","text":"A typical journey for a Developer funded by the program is organized by a series of milestones and actions. SDJS_Widget(\"9B655732E9F0B87CAE2F9687FDEDF6BCD81\",41500,1,\"\"); This journey is managed through our Ecosystem Management Platform. If you do not yet have access to the platform, send us a request . This process should be followed by most Developers who are funded through Venafi's Development Fund Program . In rare cases, exceptions have to be made. In which case, you will have milestones that are not part of the five outlined above. These milestone actions will be reflected in the above-mentioned platform. For any other issues, you can send us an issue report .","title":"Milestones and Checkins"},{"location":"Getting-Started/general-inquiry/","text":"If you have a use case for an integration with Venafi: Send an us email or fill out the new use case form If you have a customer request to integration with Venafi: Send us an email or fill out the integration request form For any other inquires, you can send us a general inquiry .","title":"General Inquiry"},{"location":"Getting-Started/nav/","text":"How to Engage For Funded Developers For Existing or Prospective Customers Want to build with Venafi Development Fund Program General Inquiry","title":"Nav"},{"location":"Getting-Started/prospective-developers/","text":"Venafi Ecosystem is always welcoming new and past Developers to join and participate in building the future where all machine identities are protected. Developers get access to: Common design patterns and guides Kits with simulators for amazingly fast dev and test Pre-configured cloud instances for immediate, on-demand development Free and extensible trial for Venafi cloud Full support from Venafi engineers Go-to-market leadership ready to educate and drive demand To become a Developer of Venafi Ecosystem, please check out the following pages for details: Development Fund Program \u00b6 General Inquiry \u00b6 For any other issues, you can send us an issue report .","title":"Want to build with Venafi"},{"location":"Manifesto/nav/","text":"Core Statement Operating Principles","title":"Nav"},{"location":"Manifesto/operating-principles/","text":"Venafi Ecosystem decision making is guided by 8 core principles: Ecosystem always futureproofs customer success \u2013 for the organization, team, champion, and their career \u2013 by bringing together the world\u2019s leaders and innovators to solve 100% of Machine Identity Management problems required today and into the future. The Ecosystem predicts the future needs of Customers ahead of their needs; with Customers continuing to use more of Venafi to solve Machine Identity Management problems and increase their success with Ecosystem-developed solutions. Ecosystem values every developer and is building for developer success . Developers have every opportunity to complete projects, promote to Customers, drive use by Customers, increase contribution, and grow licensed revenue. Ecosystem enables Developers to build more innovation faster without wasting time. Developers value this and see the benefit in time to get their innovation to Customers, write less code, update faster, and see use grow faster. Ecosystem always innovates, never copies to futureproof customer success . Ecosystem initiatives are unique to Venafi and never copies of a competitor. This means the Ecosystem is always bringing new developer solutions for Machine Identity Management ahead of competition. It is always looking for new ideas from innovators not past success. Speed matters . Many decisions are reversible and do not need extensive study. Ecosystem encourages and values calculated risk taking. Ecosystem values failures as opportunities to learn from. Ecosystem is never afraid to fail and learn more to improve. Because the Ecosystem is working to the future, it accepts that it may be misunderstood for long periods of time. Ecosystem is always improving the developer experience so that almost all developer project started are completed and that every year the time to complete projects decreases by 50%. Wherever possible, developer experience is focused on a more gamified and interactive approach, rather than a checkbox exercise. Ecosystem builds intelligence by collecting developer and customer usage data so that 100% of customer use of Marketplace and 100% use by Customers of developer solutions can be learned from and used to provide new insights and improvements that futureproofs customer success. Ecosystem makes sure 100% of Developers are never left behind to futureproof customer success when updates to Venafi APIs are made by providing training, documentation, tools that make any transition and updates easy and fast. Ecosystem certifies 100% of new developer solutions that meet published Venafi standards to futureproof customer success and 100% of existing developer solutions are recertified at least once per year.","title":"Operating Principles"},{"location":"Manifesto/statements/","text":"The Venafi Ecosystem (\"Ecosystem\") is the innovation engine that futureproofs Customer success. Ecosystem innovation is the identification and development of new design patterns, solving problems in new ways, and building new business models - all of which makes it easier, faster, consistent, and reliable for Customers to use Machine Identity Management. The Ecosystem prioritizes outcomes for the Design Customer of the Future. Venafi is the organizer and a participant in the Ecosystem where the majority of solutions are built by external Developers and Customers. Developers are startups, consultancies, leading technologies, and individuals that create solutions that perform or make use of Machine Identity Management. Innovation occurs naturally with the most diverse range of Developers building solutions that benefit Venafi Customers. The outcome is that Customers have the confidence to deliver their Machine Identity Management strategy today and into the future. A clear measure of Customer confidence is consistent, increasing use of Ecosystem-developed solutions. This drives a secondary measure: more Developers build more solutions for Venafi Customers, increasing the diversity in terms of Developers and offerings. Each year at least 20 Developers come to Venafi to join the Ecosystem and build for Venafi. All of this makes it easier and faster for Venafi to recruit new Developers to the Ecosystem. And thirdly: more Developers are educating on the need and correct design pattern for Machine Identity Management.","title":"Core Statement"},{"location":"Programs/devfund/","text":"Technology is advancing faster than ever before, software development is going faster, innovation is driven to go with a faster speed. To help with fastsecure with machine identity management, Venafi established a $12.5 million Development Fund to bring to life new integrated solutions for DevOps, cloud native, microservices, IoT and beyond. Under the management of Venafi Ecosystem, we seek for innovation that identifies and develops new design patterns, finds new ways of solving problems, and builds new business models. Submit your idea by filling out this DevFund Application Developers \u00b6 In addition to traditional parnter Developers , we extend our offer to the following types of Developers. Venafi IndieDevs \u00b6 Individual developers make a unique contribution to the open-source community and will provide Venafi customers with cutting edge solutions in the machine identity management space. An indieDev can belong to an organization with the exception of Venafi competitors, but the contract is between Venafi and the individual. Venafi UniversityDevs \u00b6 Venafi is expanding the network of innovation to top universities in the world. Oxford University and Carnegie Mellon University are now investigating machine identity management innovations and creating new open-source solutions. Process \u00b6 SDJS_Widget(\"BED58066764839EECE7278C0D8B6645F61F\",69931,1,\"\"); Principles \u00b6 Venafi does not dictate the speed of your progress We do not impose on any timeline for the completion of each milestone or the project We care about the results, the outcome, not your day-to-day process Developer takes the initiative informing Ecosystem team when you are ready to deliver and we will set up meetings to evaluate We approve the deliverables for each milestone when they meet production quality that is normally expected for an enterprise solution We provide feedback per request Developer owns the intellectural property rights We invoice if the deliverables meet the above stated standard AND the Venafi team explicitly approves the quality of the deliverables, per the SOE agreement Innovative solutions \u00b6 Venafi Ecosystem has successfully sponsored a diverse group of Developers who built innovations that are listed on Venafi Marketplace .","title":"Development Fund Program"},{"location":"Programs/devfund/#developers","text":"In addition to traditional parnter Developers , we extend our offer to the following types of Developers.","title":"Developers"},{"location":"Programs/devfund/#process","text":"SDJS_Widget(\"BED58066764839EECE7278C0D8B6645F61F\",69931,1,\"\");","title":"Process"},{"location":"Programs/devfund/#principles","text":"Venafi does not dictate the speed of your progress We do not impose on any timeline for the completion of each milestone or the project We care about the results, the outcome, not your day-to-day process Developer takes the initiative informing Ecosystem team when you are ready to deliver and we will set up meetings to evaluate We approve the deliverables for each milestone when they meet production quality that is normally expected for an enterprise solution We provide feedback per request Developer owns the intellectural property rights We invoice if the deliverables meet the above stated standard AND the Venafi team explicitly approves the quality of the deliverables, per the SOE agreement","title":"Principles"},{"location":"Programs/devfund/#innovative-solutions","text":"Venafi Ecosystem has successfully sponsored a diverse group of Developers who built innovations that are listed on Venafi Marketplace .","title":"Innovative solutions"},{"location":"Testing-Ground/testing-diagrams/","text":"Testing Diagrams \u00b6 Here's an example of a diagram: %%{ init: { \"sequence\": { \"showSequenceNumbers\": true, \"messageAlign\": \"center\" } } }%% sequenceDiagram actor EU as User participant IP as Integrated Platform participant V as Venafi activate EU EU->IP: Enter required SERVICE ACCOUNT connection information (Venafi URL/ClientID/Username/Password) deactivate EU activate IP IP->IP: Store required connection information SECURELY activate V IP->V: Use connection information to call '/vedauth/authorize' providing UN, PW, ClientID, & Scope V-->IP: Returns Access/Refresh tokens and expiry information IP->IP: Store tokens & expiry info IP->V: Use 'access_token' to authorize API calls to Venafi alt [access_token is still valid] V-->IP: API call returns data successfully else [access_token is expired] V-->IP: Returns 'access_token is expired' IP->V: Calls '/vedauth/authorize/' providing ClientID & refresh_token V-->IP: Returns fresh Access/Refresh tokens & expiry info IP->IP: Update stored tokens & expiry info with new values IP->V: Use 'access_token' to authorize API calls to Venafi V-->IP: API call returns data successfully end IP->V: Call 'vedauth/Revoke/token' to clean up active grant deactivate IP deactivate V","title":"Testing Diagrams"},{"location":"Testing-Ground/testing-diagrams/#testing-diagrams","text":"Here's an example of a diagram: %%{ init: { \"sequence\": { \"showSequenceNumbers\": true, \"messageAlign\": \"center\" } } }%% sequenceDiagram actor EU as User participant IP as Integrated Platform participant V as Venafi activate EU EU->IP: Enter required SERVICE ACCOUNT connection information (Venafi URL/ClientID/Username/Password) deactivate EU activate IP IP->IP: Store required connection information SECURELY activate V IP->V: Use connection information to call '/vedauth/authorize' providing UN, PW, ClientID, & Scope V-->IP: Returns Access/Refresh tokens and expiry information IP->IP: Store tokens & expiry info IP->V: Use 'access_token' to authorize API calls to Venafi alt [access_token is still valid] V-->IP: API call returns data successfully else [access_token is expired] V-->IP: Returns 'access_token is expired' IP->V: Calls '/vedauth/authorize/' providing ClientID & refresh_token V-->IP: Returns fresh Access/Refresh tokens & expiry info IP->IP: Update stored tokens & expiry info with new values IP->V: Use 'access_token' to authorize API calls to Venafi V-->IP: API call returns data successfully end IP->V: Call 'vedauth/Revoke/token' to clean up active grant deactivate IP deactivate V","title":"Testing Diagrams"},{"location":"Testing-Ground/testing-fullpage-embeds/","text":"Embedding Things \u00b6 (function() { var script = document.createElement('script'); script.src = \"https://paperform.co/__embed.min.js\";document.body.appendChild(script); })()","title":"Embedding Things"},{"location":"Testing-Ground/testing-fullpage-embeds/#embedding-things","text":"(function() { var script = document.createElement('script'); script.src = \"https://paperform.co/__embed.min.js\";document.body.appendChild(script); })()","title":"Embedding Things"},{"location":"Testing-Ground/testing-inline-embeds/","text":"Embedding Things \u00b6 (function() {var script = document.createElement('script'); script.src = \"https://paperform.co/__embed.min.js\"; document.body.appendChild(script); })()","title":"Embedding Things"},{"location":"Testing-Ground/testing-inline-embeds/#embedding-things","text":"(function() {var script = document.createElement('script'); script.src = \"https://paperform.co/__embed.min.js\"; document.body.appendChild(script); })()","title":"Embedding Things"},{"location":"Tools/nav/","text":"For Developers VCert APIs Adaptable Framework HSM Validation Utility","title":"Nav"},{"location":"Tools/API/overview-api/","text":"Venafi REST APIs \u00b6 The Venafi TLS Protect Cloud and TLS Protect Datacenter REST APIs enable developers to seamlessly integrate machine identity management into other products, platforms and services. Building your solution using Venafi APIs provides an excellent experience for the end user because they don't need to download or install any additional bits - typically they just have to follow a simple configuration process to establish connection between Venafi and the target application, service or platform. Once complete, users are able to perform all necessary functions involving machine identities directly from the interfaces and platforms they're already using every day. Official API Documentation \u00b6 TLS Protect Cloud TLS Protect Datacenter","title":"APIs"},{"location":"Tools/API/overview-api/#venafi-rest-apis","text":"The Venafi TLS Protect Cloud and TLS Protect Datacenter REST APIs enable developers to seamlessly integrate machine identity management into other products, platforms and services. Building your solution using Venafi APIs provides an excellent experience for the end user because they don't need to download or install any additional bits - typically they just have to follow a simple configuration process to establish connection between Venafi and the target application, service or platform. Once complete, users are able to perform all necessary functions involving machine identities directly from the interfaces and platforms they're already using every day.","title":"Venafi REST APIs"},{"location":"Tools/API/overview-api/#official-api-documentation","text":"TLS Protect Cloud TLS Protect Datacenter","title":"Official API Documentation"},{"location":"Tools/API/Cloud/0-intro-cloud-api/","text":"General Tips \u00b6 Ideally, certificates should be referenced using the GUID of the certificate object Listing all certificates in a folder could be problematic because there may be a very high number of certificates in some policy folders. A better approach would be to check (search) whether a specific certificate already exists within a given policy folder.","title":"0 intro cloud api"},{"location":"Tools/API/Cloud/0-intro-cloud-api/#general-tips","text":"Ideally, certificates should be referenced using the GUID of the certificate object Listing all certificates in a folder could be problematic because there may be a very high number of certificates in some policy folders. A better approach would be to check (search) whether a specific certificate already exists within a given policy folder.","title":"General Tips"},{"location":"Tools/API/Datacenter/0-intro-datacenter-api/","text":"","title":"0 intro datacenter api"},{"location":"Tools/Adaptable-Framework/0-intro-adaptable-framework/","text":"Adaptable Framework \u00b6 Venafi Adaptable Drivers provide a quick, easy framework to build solutions, primarily with target application platforms (web servers, network devices, application firewalls, etc.) and CAs (certificate authorities), but also to support flexible workflow and logging needs for unique environments or use cases. It will likely become clear over the next few pages which specific Adaptable Framework type is applicable to your use case. Use the power of the Ecosystem! If you still aren't sure which Adaptable Driver type best supports your target use case after reading through the next few pages, describe your use case to the Venafi Warrior Community to see what is recommended! Each of Venafi's Adaptable Drivers provides a common set of variables required by the majority of applicable use cases that are supported by TLS Protect Datacenter natively, including things like the hostname/IP of the target application device or cloud service, as well as the necessary credentials to make the connection to the target. This data can be referenced/retrieved from Venafi by using hash tables included in each function in the Adaptable Driver - more on this later. Some Adaptable Drivers also let you define additional text fields, yes/no (boolean) fields, and an additional password credential field, which you can then use to elicit different behaviors or to pass additional data to the system or service to which you are building a solution. Each type of Adaptable Driver will have slightly different options for customization. These will be described in more detail in the complete documentation after you've selected which type of Adaptable Driver you will be writing. Adaptable drivers depend on a Microsoft PowerShell script hosted on each Venafi server to execute functions corresponding to standard certificate lifecycle stages or TLS Protect Datacenter events. Note To work effectively with any Venafi Adaptable solution, you must have some working knowledge of PowerShell scripting, or you must have equivalent experience with a scripting language similar to PowerShell.","title":"Adaptable Framework"},{"location":"Tools/Adaptable-Framework/0-intro-adaptable-framework/#adaptable-framework","text":"Venafi Adaptable Drivers provide a quick, easy framework to build solutions, primarily with target application platforms (web servers, network devices, application firewalls, etc.) and CAs (certificate authorities), but also to support flexible workflow and logging needs for unique environments or use cases. It will likely become clear over the next few pages which specific Adaptable Framework type is applicable to your use case. Use the power of the Ecosystem! If you still aren't sure which Adaptable Driver type best supports your target use case after reading through the next few pages, describe your use case to the Venafi Warrior Community to see what is recommended! Each of Venafi's Adaptable Drivers provides a common set of variables required by the majority of applicable use cases that are supported by TLS Protect Datacenter natively, including things like the hostname/IP of the target application device or cloud service, as well as the necessary credentials to make the connection to the target. This data can be referenced/retrieved from Venafi by using hash tables included in each function in the Adaptable Driver - more on this later. Some Adaptable Drivers also let you define additional text fields, yes/no (boolean) fields, and an additional password credential field, which you can then use to elicit different behaviors or to pass additional data to the system or service to which you are building a solution. Each type of Adaptable Driver will have slightly different options for customization. These will be described in more detail in the complete documentation after you've selected which type of Adaptable Driver you will be writing. Adaptable drivers depend on a Microsoft PowerShell script hosted on each Venafi server to execute functions corresponding to standard certificate lifecycle stages or TLS Protect Datacenter events. Note To work effectively with any Venafi Adaptable solution, you must have some working knowledge of PowerShell scripting, or you must have equivalent experience with a scripting language similar to PowerShell.","title":"Adaptable Framework"},{"location":"Tools/Adaptable-Framework/1-prereqs-adaptable-framework/","text":"Prerequisites \u00b6 Before you begin writing an Adaptable Driver, there are a few important things to consider. Note Venafi Adaptable Drivers support Venafi TLS Protect Datacenter only. Venafi Product Management is working on a similar framework for TLS Protect Cloud use cases. Please sign up here to be notified when developer tools are available for TLS Protect Cloud . Environment Dependencies \u00b6 Since the Adaptable Framework is based on PowerShell, you'll need a Windows machine with the following: Windows PowerShell 5.1 Warning PowerShell 7 is not yet supported by TLS Protect Datacenter .NET 4.7.2 or later TLS 1.3 If your product does not support TLS 1.3, you will need to add the following code to your Adaptable script in order for it to work with the Venafi Platform. [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls -bor [Net.SecurityProtocolType]::Tls11 -bor [Net.SecurityProtocolType]::Tls12 Other Considerations \u00b6 In most cases, any information required by both Venafi and the target integrated solution can be passed to and from Venafi through the Adaptable Driver script and the existing functions contained therein. That said, there are certain scenarios which require interacting directly with the API. Calling Venafi APIs from Adaptable Drivers \u00b6 If your Adaptable Driver requires access to the Venafi API, you'll need to do the following: Create an API Application Integration that's specific to your script. This is a required step in which you register your application with Trust Protection Platform. For more information, see Integrating other systems with Venafi products . Best Practice When creating your API Application Integration for use with OAuth, consider the following best practice settings. Under Access Limits in the Create Application Integration panel, select these options: Set Grant and token expiration to Configure Set Grant Expiration Period to 1 day Set Token Refresh to Disabled If you don't already have one, create a Username credential that has been associated with a service account that has permissions to the API application. See Creating user name or password credentials . Unique use cases like this one should be rare, but occasionally do present themselves and require additional consideration. Use the power of the Ecosystem! In the event you need functionality that isn't supported by the Adaptable Driver framework natively, please check the Venafi Warrior Community to see if your question might have already been asked by previous developers, and if there's an accepted workaround. If not, post a new question!","title":"Prerequisites"},{"location":"Tools/Adaptable-Framework/1-prereqs-adaptable-framework/#prerequisites","text":"Before you begin writing an Adaptable Driver, there are a few important things to consider. Note Venafi Adaptable Drivers support Venafi TLS Protect Datacenter only. Venafi Product Management is working on a similar framework for TLS Protect Cloud use cases. Please sign up here to be notified when developer tools are available for TLS Protect Cloud .","title":"Prerequisites"},{"location":"Tools/Adaptable-Framework/1-prereqs-adaptable-framework/#environment-dependencies","text":"Since the Adaptable Framework is based on PowerShell, you'll need a Windows machine with the following: Windows PowerShell 5.1 Warning PowerShell 7 is not yet supported by TLS Protect Datacenter .NET 4.7.2 or later TLS 1.3 If your product does not support TLS 1.3, you will need to add the following code to your Adaptable script in order for it to work with the Venafi Platform. [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls -bor [Net.SecurityProtocolType]::Tls11 -bor [Net.SecurityProtocolType]::Tls12","title":"Environment Dependencies"},{"location":"Tools/Adaptable-Framework/1-prereqs-adaptable-framework/#other-considerations","text":"In most cases, any information required by both Venafi and the target integrated solution can be passed to and from Venafi through the Adaptable Driver script and the existing functions contained therein. That said, there are certain scenarios which require interacting directly with the API.","title":"Other Considerations"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/","text":"Overview \u00b6 Consider the following guidelines and expected behaviors, which apply generally to all types of Adaptable Framework drivers (CA, Application, Log, Workflow, etc.). Drivers rely on System.Management.Automation in .NET to invoke PowerShell functions inside a locally hosted script PowerShell functions are responsible for ensuring that data meets the requirements of the integration point All functions (except where noted) must be present in the script, but they are optional from a logic standpoint. Hash Tables \u00b6 Venafi passes variables to (and receives them from) PowerShell functions in the form of hash tables, which are generally easier to work with and allow for the addition of variables without changing the function definition. A general hash table, $General , which includes a common set of data available from Venafi, is passed to all the functions A specific hash table, $Specific , which includes data that is applicable only to the specific function, is passed to some functions that require additional data All functions must return a single hash table that includes a result along with any other variables that the function is required to return - check the documentation for the function in question to see what is expected in the return Naming Conventions \u00b6 To avoid collisions, you should adopt a standard naming convention that will be used when creating objects (certificates, devices, applications) in Venafi. Collisions can occur when the name you define already exists in Venafi's inventory. One option to avoid collisions is to use the same prefix or suffix, and then add something unique to the name. Suppose your driver connects to a device object via API and imports all the machine identities currently in use on the device. In addition to the certificates themselves being imported, a unique application object must be created as well, which will contain all the metadata (port, partition, profile, configuration options, etc.) needed for Venafi to automatically provision that certificate during a renewal. Note When creating new PowerShell scripts for use with adaptable drivers, keep in mind that the file name is used to identify your script from within the associated object (and within the policy for the Adaptable Application driver) in Trust Protection Platform. Using logical names can help you and other administrators recognize the purpose and intent of each script. Credentials & Authentication \u00b6 Credential objects store the credentials Trust Protection Platform uses to authenticate with devices, applications, CAs, and other systems in a user's infrastructure. The stored credential may be a password, a username and password, a certificate, a file paired with a password, or a private key. Trust Protection Platform requires these credentials so it can manage the certificates associated with these devices, applications, and CAs. Credential objects provide an innovative way to centrally manage and share your system credentials. Each credential object can be associated with a single device or application, or it can be shared by multiple objects. After you create your system\u2019s credential objects, you do not have to repeat the credential configuration for each device or application. You simply reference the existing credential object. If the credential changes\u2014for example, an organization might change username and password credentials every 90 days\u2014you merely update the single credential object to give Trust Protection Platform access to all associated devices and applications. Reuse credential objects wherever standardization is possible to avoid creating extraneous objects. Recommend assigning credentials to a Policy folder that contains multiple devices. The policy credentials allow multiple devices to use the same credential. Certificate \"Installations\" \u00b6 Within a customer\u2019s environment, there may be circumstances that require the same certificate to be installed in multiple locations (high-availability, load balancing, traffic inspection, etc.). If that is the case, the Venafi platform must be made aware of each location. This ensures there are no blind spots for the Security or PKI team, and also provides Venafi the information necessary to automatically provision and activate that certificate during future renewal operations. Possible Outage! If your application supports multiple installations of the same certificate, it is critical that ALL those locations are reported back to Venafi. Data Validation \u00b6 You should implement effective data validation in order to catch errors in the script: Check values for validity that are being passed into functions Check values for validity before passing data back to Venafi Logging \u00b6 Generally, Adaptable Framework scripts don\u2019t need to do any logging unless it\u2019s for temporary, debugging purposes. The Adaptable drivers are logging to the standard Venafi logging channel when they call various PowerShell functions. Beginning in v19.3, developers can toggle debug logging for individual Adaptable drivers. This sets a $DEBUG_FILE global variable in the Adaptable driver. If toggled on, the script should be logging \u2013 If toggled off, it shouldn\u2019t. The $DEBUG_FILE variable gets set automatically to a suggested file path on the Venafi server for the script to write logs to, using a unique identifier. This is to avoid issues if there are multiple instances trying to write data to the same file. The resulting log file appears in the \\Logs directory by default. (e.g. C:\\Program Files\\Venafi\\Logs ) Permanent Logs If additional, permanent logs are needed, use Write-EventLog to capture important logging and debug information to the Windows Event Log Error Handling \u00b6 PowerShell functions must not return errors; rather, they must throw exceptions in the same way that actual PowerShell errors do. Adaptable drivers treat exceptions thrown by a PowerShell function as a fatal error and then halt processing. Thrown exceptions are handled as unexpected. If there is an error, we recommended you use Result=\"Failure\" and pass the error description in the Error=\"\" parameter. Please write effective error messages that tell users what went wrong and how to fix the issue.","title":"Overview"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#overview","text":"Consider the following guidelines and expected behaviors, which apply generally to all types of Adaptable Framework drivers (CA, Application, Log, Workflow, etc.). Drivers rely on System.Management.Automation in .NET to invoke PowerShell functions inside a locally hosted script PowerShell functions are responsible for ensuring that data meets the requirements of the integration point All functions (except where noted) must be present in the script, but they are optional from a logic standpoint.","title":"Overview"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#hash-tables","text":"Venafi passes variables to (and receives them from) PowerShell functions in the form of hash tables, which are generally easier to work with and allow for the addition of variables without changing the function definition. A general hash table, $General , which includes a common set of data available from Venafi, is passed to all the functions A specific hash table, $Specific , which includes data that is applicable only to the specific function, is passed to some functions that require additional data All functions must return a single hash table that includes a result along with any other variables that the function is required to return - check the documentation for the function in question to see what is expected in the return","title":"Hash Tables"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#naming-conventions","text":"To avoid collisions, you should adopt a standard naming convention that will be used when creating objects (certificates, devices, applications) in Venafi. Collisions can occur when the name you define already exists in Venafi's inventory. One option to avoid collisions is to use the same prefix or suffix, and then add something unique to the name. Suppose your driver connects to a device object via API and imports all the machine identities currently in use on the device. In addition to the certificates themselves being imported, a unique application object must be created as well, which will contain all the metadata (port, partition, profile, configuration options, etc.) needed for Venafi to automatically provision that certificate during a renewal. Note When creating new PowerShell scripts for use with adaptable drivers, keep in mind that the file name is used to identify your script from within the associated object (and within the policy for the Adaptable Application driver) in Trust Protection Platform. Using logical names can help you and other administrators recognize the purpose and intent of each script.","title":"Naming Conventions"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#credentials-authentication","text":"Credential objects store the credentials Trust Protection Platform uses to authenticate with devices, applications, CAs, and other systems in a user's infrastructure. The stored credential may be a password, a username and password, a certificate, a file paired with a password, or a private key. Trust Protection Platform requires these credentials so it can manage the certificates associated with these devices, applications, and CAs. Credential objects provide an innovative way to centrally manage and share your system credentials. Each credential object can be associated with a single device or application, or it can be shared by multiple objects. After you create your system\u2019s credential objects, you do not have to repeat the credential configuration for each device or application. You simply reference the existing credential object. If the credential changes\u2014for example, an organization might change username and password credentials every 90 days\u2014you merely update the single credential object to give Trust Protection Platform access to all associated devices and applications. Reuse credential objects wherever standardization is possible to avoid creating extraneous objects. Recommend assigning credentials to a Policy folder that contains multiple devices. The policy credentials allow multiple devices to use the same credential.","title":"Credentials & Authentication"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#certificate-installations","text":"Within a customer\u2019s environment, there may be circumstances that require the same certificate to be installed in multiple locations (high-availability, load balancing, traffic inspection, etc.). If that is the case, the Venafi platform must be made aware of each location. This ensures there are no blind spots for the Security or PKI team, and also provides Venafi the information necessary to automatically provision and activate that certificate during future renewal operations. Possible Outage! If your application supports multiple installations of the same certificate, it is critical that ALL those locations are reported back to Venafi.","title":"Certificate \"Installations\""},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#data-validation","text":"You should implement effective data validation in order to catch errors in the script: Check values for validity that are being passed into functions Check values for validity before passing data back to Venafi","title":"Data Validation"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#logging","text":"Generally, Adaptable Framework scripts don\u2019t need to do any logging unless it\u2019s for temporary, debugging purposes. The Adaptable drivers are logging to the standard Venafi logging channel when they call various PowerShell functions. Beginning in v19.3, developers can toggle debug logging for individual Adaptable drivers. This sets a $DEBUG_FILE global variable in the Adaptable driver. If toggled on, the script should be logging \u2013 If toggled off, it shouldn\u2019t. The $DEBUG_FILE variable gets set automatically to a suggested file path on the Venafi server for the script to write logs to, using a unique identifier. This is to avoid issues if there are multiple instances trying to write data to the same file. The resulting log file appears in the \\Logs directory by default. (e.g. C:\\Program Files\\Venafi\\Logs ) Permanent Logs If additional, permanent logs are needed, use Write-EventLog to capture important logging and debug information to the Windows Event Log","title":"Logging"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#error-handling","text":"PowerShell functions must not return errors; rather, they must throw exceptions in the same way that actual PowerShell errors do. Adaptable drivers treat exceptions thrown by a PowerShell function as a fatal error and then halt processing. Thrown exceptions are handled as unexpected. If there is an error, we recommended you use Result=\"Failure\" and pass the error description in the Error=\"\" parameter. Please write effective error messages that tell users what went wrong and how to fix the issue.","title":"Error Handling"},{"location":"Tools/Adaptable-Framework/3-writing-adaptable-drivers/","text":"Writing Adaptable Drivers \u00b6 Venafi Adaptable Drivers provide a way quick, easy framework to build solutions, primarily with target application platforms (web servers, network devices, application firewalls, etc.) and CAs (certificate authorities), but also to support flexible workflow and logging needs for unique environments. Note Venafi Adaptable Drivers support Venafi TLS Protect Datacenter only. Venafi Product Management is working on a similar framework for TLS Protect Cloud use cases. Please sign up here to be notified when developer tools are available for TLS Protect Cloud . Getting Started \u00b6 Read through this section on the Adaptable Framework (You're almost done!) Decide which DevKit you'll need below Build & test your driver using the tools provided in the DevKit Test your driver against TLS Protect Datacenter Submit your driver to Cool Solutions (Venafi's managed GitLab instance) Note You will need a Venafi user account in order to access.. Complete the Marketplace Listing Questionnaire Adaptable Driver Types \u00b6 Adaptable CA Adaptable App Adaptable Log Adaptable Workflow Adaptable Bulk Provisioning Choose this if you are building a solution between Venafi and a Machine Identity Producer , like a Certificate Authority or Managed PKI. Adaptable CA Full Documentation Choose this if you are building a solution between Venafi and a Machine Identity Consumer , like an application server, network device, WAF , etc. Adaptable Application Full Documentation Choose this if you are building a solution that will be used to perform virtually any programmatic task in response to the logging of a Venafi event. Adaptable Log Full Documentation Choose this if you are building a solution with the goal of further customizing Venafi's native approval workflows. Adaptable Workflow Full Documentation This use case is similar to the \"Adaptable App.\" The main difference is \"Bulk Provisioning\" was designed to provision many machine identities to a target using as few API calls as possible. Choose this if you are building a solution between Venafi and a Machine Identity Consumer , like a NGFW, traffic inspection device, or something else that needs many certificates with few connections to the target device. Adaptable Bulk Provisioning Full Documentation","title":"Writing Adaptable Drivers"},{"location":"Tools/Adaptable-Framework/3-writing-adaptable-drivers/#writing-adaptable-drivers","text":"Venafi Adaptable Drivers provide a way quick, easy framework to build solutions, primarily with target application platforms (web servers, network devices, application firewalls, etc.) and CAs (certificate authorities), but also to support flexible workflow and logging needs for unique environments. Note Venafi Adaptable Drivers support Venafi TLS Protect Datacenter only. Venafi Product Management is working on a similar framework for TLS Protect Cloud use cases. Please sign up here to be notified when developer tools are available for TLS Protect Cloud .","title":"Writing Adaptable Drivers"},{"location":"Tools/Adaptable-Framework/3-writing-adaptable-drivers/#getting-started","text":"Read through this section on the Adaptable Framework (You're almost done!) Decide which DevKit you'll need below Build & test your driver using the tools provided in the DevKit Test your driver against TLS Protect Datacenter Submit your driver to Cool Solutions (Venafi's managed GitLab instance) Note You will need a Venafi user account in order to access.. Complete the Marketplace Listing Questionnaire","title":"Getting Started"},{"location":"Tools/Adaptable-Framework/3-writing-adaptable-drivers/#adaptable-driver-types","text":"Adaptable CA Adaptable App Adaptable Log Adaptable Workflow Adaptable Bulk Provisioning Choose this if you are building a solution between Venafi and a Machine Identity Producer , like a Certificate Authority or Managed PKI. Adaptable CA Full Documentation Choose this if you are building a solution between Venafi and a Machine Identity Consumer , like an application server, network device, WAF , etc. Adaptable Application Full Documentation Choose this if you are building a solution that will be used to perform virtually any programmatic task in response to the logging of a Venafi event. Adaptable Log Full Documentation Choose this if you are building a solution with the goal of further customizing Venafi's native approval workflows. Adaptable Workflow Full Documentation This use case is similar to the \"Adaptable App.\" The main difference is \"Bulk Provisioning\" was designed to provision many machine identities to a target using as few API calls as possible. Choose this if you are building a solution between Venafi and a Machine Identity Consumer , like a NGFW, traffic inspection device, or something else that needs many certificates with few connections to the target device. Adaptable Bulk Provisioning Full Documentation","title":"Adaptable Driver Types"},{"location":"Tools/Adaptable-Framework/4-submitting-your-adaptable-driver/","text":"Submitting/Updating \u00b6 You've written an amazing Adaptable Driver and are now ready to make it available for users of the Machine Identity Management Control Plane . Or maybe you're ready to publish some bug fixes or feature enhancements to an existing solution. Either way, that's awesome! As a Venafi partner, you'll have a dedicated group in our GitLab instance where you can manage your own repository . New Solution \u00b6 If this is a new solution, please reach out to the Venafi Ecosystem team. Existing Solution \u00b6 If this is an update to an existing solution, please submit a Merge Request to your target repository and the update will be reviewed by the proper parties before being automatically updated on the Venafi Marketplace .","title":"Submitting/Updating"},{"location":"Tools/Adaptable-Framework/4-submitting-your-adaptable-driver/#submittingupdating","text":"You've written an amazing Adaptable Driver and are now ready to make it available for users of the Machine Identity Management Control Plane . Or maybe you're ready to publish some bug fixes or feature enhancements to an existing solution. Either way, that's awesome! As a Venafi partner, you'll have a dedicated group in our GitLab instance where you can manage your own repository .","title":"Submitting/Updating"},{"location":"Tools/Adaptable-Framework/4-submitting-your-adaptable-driver/#new-solution","text":"If this is a new solution, please reach out to the Venafi Ecosystem team.","title":"New Solution"},{"location":"Tools/Adaptable-Framework/4-submitting-your-adaptable-driver/#existing-solution","text":"If this is an update to an existing solution, please submit a Merge Request to your target repository and the update will be reviewed by the proper parties before being automatically updated on the Venafi Marketplace .","title":"Existing Solution"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/","text":"Managing Your Repo \u00b6 Venafi provides access to our managed GitLab instance to streamline code and script submissions for ecosystem solutions. GitLab provides better visibility and version control and more consistent documentation. Automations \u00b6 A number of default automations are enabled by default to enhance the user experience for both you as a developer, as well as end users of the solution. Please feel free to adapt to fit your needs. Default GitLab Pipeline \u00b6 Name Description Run Stage prepare_description.yml Reads a version.txt file in the root of the repo and stores it as $version in description.env for future use in the pipeline prepare build_pdf.yml Generates a PDF file from the README.md build release.yml Creates a release using the $version from the prepare stage and publishes the PDF version of the README release Documentation \u00b6 All repositories should include a README file with any information needed to configure the integration. An example repository with sample documentation is available here . Feel free to copy and use as a starting point. Account Required Some of the resources on this page will require a Venafi user account in order to access. Please feel free to create one. If you encounter any issues, please let us know . Docs Required All new projects and merge requests will be required to have accompanying documentation. Merge Requests \u00b6 The main branch is protected in all Ecosystem repositories. All changes must be committed to a separate branch and a merge request must be opened. Venafi teams will automatically be notified and will begin code review. We try to respond as quickly as possible. Code Review \u00b6 Venafi teams will review the committed code and merge to the main branch after passing review.","title":"Managing Your Repo"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/#managing-your-repo","text":"Venafi provides access to our managed GitLab instance to streamline code and script submissions for ecosystem solutions. GitLab provides better visibility and version control and more consistent documentation.","title":"Managing Your Repo"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/#automations","text":"A number of default automations are enabled by default to enhance the user experience for both you as a developer, as well as end users of the solution. Please feel free to adapt to fit your needs.","title":"Automations"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/#default-gitlab-pipeline","text":"Name Description Run Stage prepare_description.yml Reads a version.txt file in the root of the repo and stores it as $version in description.env for future use in the pipeline prepare build_pdf.yml Generates a PDF file from the README.md build release.yml Creates a release using the $version from the prepare stage and publishes the PDF version of the README release","title":"Default GitLab Pipeline"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/#documentation","text":"All repositories should include a README file with any information needed to configure the integration. An example repository with sample documentation is available here . Feel free to copy and use as a starting point. Account Required Some of the resources on this page will require a Venafi user account in order to access. Please feel free to create one. If you encounter any issues, please let us know . Docs Required All new projects and merge requests will be required to have accompanying documentation.","title":"Documentation"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/#merge-requests","text":"The main branch is protected in all Ecosystem repositories. All changes must be committed to a separate branch and a merge request must be opened. Venafi teams will automatically be notified and will begin code review. We try to respond as quickly as possible.","title":"Merge Requests"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/#code-review","text":"Venafi teams will review the committed code and merge to the main branch after passing review.","title":"Code Review"},{"location":"Tools/HSM-Utility/0-intro-hsm-utility/","text":"HSM Validation Utility \u00b6 Venafi Trust Protection Platform supports integrations with Hardware Security Modules (HSMs) to encrypt private keys, credentials, and other secrets stored in the database. Users can also use the HSM integration for the central generation of private keys. To be listed in the Venafi documentation as a compatible HSM provider, it's important to test and validate each use case that your HSM supports: Encrypt Secrets - Supports creation and storage of the Venafi database encryption key Private Key Generation - Supports creation and storage of private keys used for certificate generation Private Key Export - Supports export of private keys used for certificates Code Signing Certificate Private Key Generation & Storage Certify Your HSM Solution! Venafi makes it fast and easy to certify your HSM solution for use with Venafi. If you are interested in getting access to the HSM Validation Utility, please click here .","title":"HSM Validation Utility"},{"location":"Tools/HSM-Utility/0-intro-hsm-utility/#hsm-validation-utility","text":"Venafi Trust Protection Platform supports integrations with Hardware Security Modules (HSMs) to encrypt private keys, credentials, and other secrets stored in the database. Users can also use the HSM integration for the central generation of private keys. To be listed in the Venafi documentation as a compatible HSM provider, it's important to test and validate each use case that your HSM supports: Encrypt Secrets - Supports creation and storage of the Venafi database encryption key Private Key Generation - Supports creation and storage of private keys used for certificate generation Private Key Export - Supports export of private keys used for certificates Code Signing Certificate Private Key Generation & Storage Certify Your HSM Solution! Venafi makes it fast and easy to certify your HSM solution for use with Venafi. If you are interested in getting access to the HSM Validation Utility, please click here .","title":"HSM Validation Utility"},{"location":"Tools/VCert/overview-vcert/","text":"VCert \u00b6 vCert is a command line utility, SDK, and set of libraries designed to simplify key generation and enrollment of machine identities (also known as SSL/TLS certificates and keys) that comply with enterprise security policy by using Venafi. Go Python Java Ruby Since VCert enables interoperability between both Venafi TLS Protect Datacenter and TLS Protect Cloud , we ask that you test and document for each target.","title":"VCert"},{"location":"Tools/VCert/overview-vcert/#vcert","text":"vCert is a command line utility, SDK, and set of libraries designed to simplify key generation and enrollment of machine identities (also known as SSL/TLS certificates and keys) that comply with enterprise security policy by using Venafi. Go Python Java Ruby Since VCert enables interoperability between both Venafi TLS Protect Datacenter and TLS Protect Cloud , we ask that you test and document for each target.","title":"VCert"}]} \ No newline at end of file +{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"","title":"Home"},{"location":"nav/","text":"Home Getting Started Developers Tools Manifesto Marketplace","title":"Nav"},{"location":"Developers/devs-glossary/","text":"Glossary \u00b6 Term Definition Certificate Authority An entity that signs, and issues digital certificates CRD Custom Resource Definition: an extension of the Kubernetes API Downtime A period of time where the workload is unintentionally inaccessible Ingress Controller Specialized load balancers for Kubernetes and other containerized environments Machine Identity X.509 certificates, SSH keys, code signing certificates, etc., used to secure applications, traffic, code & organizations Machine Identity Management Control Plane The holistic platform/service, along with the cultivation & curation of the vast marketplace of solutions, tools & frameworks offered by Venafi and the ecosystem TLS Protect Cloud Venafi's SaaS offering (formerly known as Venafi as a Service) TLS Protect Datacenter Venafi's Datacenter offering (formerly known as Trust Protection Platform TLS Protect For Kubernetes Jetstack's SaaS offering (formerly known as Jetstack Secure) WAF Web Application Firewall: used to protect web apps from malicious traffic Workloads A process or any location where compute resources are consumed. Workloads in Kubernetes are pods","title":"Glossary"},{"location":"Developers/devs-glossary/#glossary","text":"Term Definition Certificate Authority An entity that signs, and issues digital certificates CRD Custom Resource Definition: an extension of the Kubernetes API Downtime A period of time where the workload is unintentionally inaccessible Ingress Controller Specialized load balancers for Kubernetes and other containerized environments Machine Identity X.509 certificates, SSH keys, code signing certificates, etc., used to secure applications, traffic, code & organizations Machine Identity Management Control Plane The holistic platform/service, along with the cultivation & curation of the vast marketplace of solutions, tools & frameworks offered by Venafi and the ecosystem TLS Protect Cloud Venafi's SaaS offering (formerly known as Venafi as a Service) TLS Protect Datacenter Venafi's Datacenter offering (formerly known as Trust Protection Platform TLS Protect For Kubernetes Jetstack's SaaS offering (formerly known as Jetstack Secure) WAF Web Application Firewall: used to protect web apps from malicious traffic Workloads A process or any location where compute resources are consumed. Workloads in Kubernetes are pods","title":"Glossary"},{"location":"Developers/devs-welcome/","text":"Welcome Developers \u00b6 This is where you'll find everything you need to develop new and exciting solutions focused on machine identity management. There are design patterns for getting started on your use case as quickly as possible, code examples, doc examples, Venafi libraries in the language of your choice, and more. If you see anything missing, please let us know . Getting Started \u00b6 If you've already got an idea about what you'd like to build in mind, but aren't sure where to start, please click here to answer a few questions that will help. If you already know the path your development will take, or you've been here before, the links are to the left.","title":"Welcome"},{"location":"Developers/devs-welcome/#welcome-developers","text":"This is where you'll find everything you need to develop new and exciting solutions focused on machine identity management. There are design patterns for getting started on your use case as quickly as possible, code examples, doc examples, Venafi libraries in the language of your choice, and more. If you see anything missing, please let us know .","title":"Welcome Developers"},{"location":"Developers/devs-welcome/#getting-started","text":"If you've already got an idea about what you'd like to build in mind, but aren't sure where to start, please click here to answer a few questions that will help. If you already know the path your development will take, or you've been here before, the links are to the left.","title":"Getting Started"},{"location":"Developers/nav/","text":"Welcome Glossary Design Patterns Certification","title":"Nav"},{"location":"Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/","text":"Certification - TLS Protect Cloud \u00b6 This page is meant to be your home base throughout the certification process, so please feel free to jump around, read ahead, bookmark and come back to it as needed. Ready to certify? If you've already completed your solution, understand and meet the necessary requirements and are ready to submit a request for Certification, you can start here. Introduction \u00b6 As a TLS Protect Cloud Certified solution, Venafi users have an extra level of confidence that your solution was designed with their best interests at the forefront. For that reason, certified solutions see more adoption from our mutual users. When building an solution to TLS Protect Cloud , one desired outcome should be official certification. Official certification is the first step to listing the solution on the Venafi Marketplace , which is the #1 way end users discover and deploy solutions. Certification is the only way that an solution will be listed on the Venafi Marketplace as compatible with TLS Protect Cloud . The TLS Protect Cloud Certification Program is still evolving and so some specifics about the following requirements are subject to change. Ample notice will be given to any developers of an existing certified solution, ensuring plenty of time to make any necessary updates to maintain certification. The following requirements are applicable to every TLS Protect Cloud solution, however there may be additional, unlisted requirements depending on the specific use case of the solution. There will be solutions and use cases that come forward that are totally new and unique from every solution that has gone through the certification process - and that's GREAT! It means machine identity management is continuing to evolve and see continued adoption. We're all in this together In cases where the Venafi team requests additional requirements be met, we will work with you to determine what success looks like and do our best to provide any Tools/guidance necessary to reach certification. Technical Certification vs. Partner Program \u00b6 The technical certification process is not to be confused with Venafi Partnership, though the two are related. The best way to think about it would be \"Packaging\" vs. \"Marketing\". Packaging \u00b6 The final step of the TLS Protect Cloud certification process will be Packaging - deciding how end users will deploy and interact with your solution. In order for end users to discover the solution and establish a strong user base, the packaging of the solution should be polished and easy to understand. Use of company logos, iconography, product names, marketing copy, etc. will all help users quickly identify your solution in the growing Venafi Marketplace . Marketing \u00b6 Marketing , on the other hand, focuses on bringing attention to a fully packaged & published solution. Once the solution has been certified and the initial Marketplace Listing has been created, the next logical step would be an official partnership with Venafi, which will also engage the Venafi Marketing team to start making some noise about the new solution available to Venafi users.","title":"TLS Protect Cloud"},{"location":"Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/#certification-tls-protect-cloud","text":"This page is meant to be your home base throughout the certification process, so please feel free to jump around, read ahead, bookmark and come back to it as needed. Ready to certify? If you've already completed your solution, understand and meet the necessary requirements and are ready to submit a request for Certification, you can start here.","title":"Certification - TLS Protect Cloud"},{"location":"Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/#introduction","text":"As a TLS Protect Cloud Certified solution, Venafi users have an extra level of confidence that your solution was designed with their best interests at the forefront. For that reason, certified solutions see more adoption from our mutual users. When building an solution to TLS Protect Cloud , one desired outcome should be official certification. Official certification is the first step to listing the solution on the Venafi Marketplace , which is the #1 way end users discover and deploy solutions. Certification is the only way that an solution will be listed on the Venafi Marketplace as compatible with TLS Protect Cloud . The TLS Protect Cloud Certification Program is still evolving and so some specifics about the following requirements are subject to change. Ample notice will be given to any developers of an existing certified solution, ensuring plenty of time to make any necessary updates to maintain certification. The following requirements are applicable to every TLS Protect Cloud solution, however there may be additional, unlisted requirements depending on the specific use case of the solution. There will be solutions and use cases that come forward that are totally new and unique from every solution that has gone through the certification process - and that's GREAT! It means machine identity management is continuing to evolve and see continued adoption. We're all in this together In cases where the Venafi team requests additional requirements be met, we will work with you to determine what success looks like and do our best to provide any Tools/guidance necessary to reach certification.","title":"Introduction"},{"location":"Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/#technical-certification-vs-partner-program","text":"The technical certification process is not to be confused with Venafi Partnership, though the two are related. The best way to think about it would be \"Packaging\" vs. \"Marketing\".","title":"Technical Certification vs. Partner Program"},{"location":"Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/#packaging","text":"The final step of the TLS Protect Cloud certification process will be Packaging - deciding how end users will deploy and interact with your solution. In order for end users to discover the solution and establish a strong user base, the packaging of the solution should be polished and easy to understand. Use of company logos, iconography, product names, marketing copy, etc. will all help users quickly identify your solution in the growing Venafi Marketplace .","title":"Packaging"},{"location":"Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/#marketing","text":"Marketing , on the other hand, focuses on bringing attention to a fully packaged & published solution. Once the solution has been certified and the initial Marketplace Listing has been created, the next logical step would be an official partnership with Venafi, which will also engage the Venafi Marketing team to start making some noise about the new solution available to Venafi users.","title":"Marketing"},{"location":"Developers/Certification/TLS-Protect-Cloud/2-tlsp-certification-reqs/","text":"Requirements \u00b6 There are currently two levels of certification for TLS Protect Cloud solutions, Foundation Certification and Advanced Certification . It's our hope that every developer strives for the most comprehensive solution, but understand that isn't always possible due to resource and/or time constraints. The purpose of creating multiple levels of certification is two-fold: It provides a lower barrier to entry for smaller organizations and individual contributors It provides an opportunity for developers to further differentiate their solution by providing additional collateral that will help end users get started #fastsecure when using the solution. Meeting the requirements for Foundation Certification should be the first point of focus for any new developer. These requirements have been designed to create a simple pathway for developers to get a listing onto the Venafi Marketplace, while ensuring a consistent, stable experience for all TLS Protect Cloud end users. All TLS Protect Cloud solutions that are published on the Venafi Marketplace are required to meet the requirements for Foundation Certification. Advanced Certification provides a means to differentiate an solution that goes above & beyond the requirements specified above. Functionally, both Foundation Certification and Advanced Certification have the same technical requirements. The difference between the two levels is really about end user enablement and ongoing testing to ensure the solution remains fully functional. From an end user's perspective, generally the more collateral available to be consumed, the less likely end users are to have questions that might block them from testing and ultimately utilizing the solution. The easier it is to deploy and test the solution, the more widely adopted that solution becomes throughout the user base. More users generate more feedback and ideas, and the solution becomes more robust as a result. Certification Requirements \u00b6 Foundation Advanced The description of the solution is an accurate representation of functionality. The solution doesn't interfere with TLS Protect Cloud native functionality or performance. The solution was developed with overall security best practices in mind and makes no attempts to harvest user data. The solution uses generally available interfaces to interact with TLS Protect Cloud (VCert, REST API, etc.). Accompanying documentation must be packaged with the solution and should include any necessary configuration instructions as well as clear usage examples. Templates are provided for this purpose. ( NOTE: a free Venafi Account will be required to access this resource) The support model is clearly defined for all user types. A demonstration of all documented functionality must be scheduled & completed with the Venafi Ecosystem team. Everything listed in the Foundation Certification Requirements section tab be completed, in addition to the following: A 5-10 minute technical demonstration video covering any initial configuration and typical usage examples must be available online. When necessary, and if possible/feasible for the solution, a test instance or account will be provided to the Venafi Ecosystem team for internal testing and demonstration purposes. Automated testing must be put in place to test all documented functionality of your solution. All REST endpoints and/or VCert functions used by the solution must be documented and provided to Venafi. These will be used internally by Venafi to track which features & functions are being used most by developers and end users. They will not be shared publicly. Do you have feedback about the certification process? We've tried to make the certification process as simple and pain free as possible, but we're always looking to make it better. If you have any suggestions or feedback to improve the process, we'd love to hear them !","title":"Requirements"},{"location":"Developers/Certification/TLS-Protect-Cloud/2-tlsp-certification-reqs/#requirements","text":"There are currently two levels of certification for TLS Protect Cloud solutions, Foundation Certification and Advanced Certification . It's our hope that every developer strives for the most comprehensive solution, but understand that isn't always possible due to resource and/or time constraints. The purpose of creating multiple levels of certification is two-fold: It provides a lower barrier to entry for smaller organizations and individual contributors It provides an opportunity for developers to further differentiate their solution by providing additional collateral that will help end users get started #fastsecure when using the solution. Meeting the requirements for Foundation Certification should be the first point of focus for any new developer. These requirements have been designed to create a simple pathway for developers to get a listing onto the Venafi Marketplace, while ensuring a consistent, stable experience for all TLS Protect Cloud end users. All TLS Protect Cloud solutions that are published on the Venafi Marketplace are required to meet the requirements for Foundation Certification. Advanced Certification provides a means to differentiate an solution that goes above & beyond the requirements specified above. Functionally, both Foundation Certification and Advanced Certification have the same technical requirements. The difference between the two levels is really about end user enablement and ongoing testing to ensure the solution remains fully functional. From an end user's perspective, generally the more collateral available to be consumed, the less likely end users are to have questions that might block them from testing and ultimately utilizing the solution. The easier it is to deploy and test the solution, the more widely adopted that solution becomes throughout the user base. More users generate more feedback and ideas, and the solution becomes more robust as a result.","title":"Requirements"},{"location":"Developers/Certification/TLS-Protect-Cloud/2-tlsp-certification-reqs/#certification-requirements","text":"Foundation Advanced The description of the solution is an accurate representation of functionality. The solution doesn't interfere with TLS Protect Cloud native functionality or performance. The solution was developed with overall security best practices in mind and makes no attempts to harvest user data. The solution uses generally available interfaces to interact with TLS Protect Cloud (VCert, REST API, etc.). Accompanying documentation must be packaged with the solution and should include any necessary configuration instructions as well as clear usage examples. Templates are provided for this purpose. ( NOTE: a free Venafi Account will be required to access this resource) The support model is clearly defined for all user types. A demonstration of all documented functionality must be scheduled & completed with the Venafi Ecosystem team. Everything listed in the Foundation Certification Requirements section tab be completed, in addition to the following: A 5-10 minute technical demonstration video covering any initial configuration and typical usage examples must be available online. When necessary, and if possible/feasible for the solution, a test instance or account will be provided to the Venafi Ecosystem team for internal testing and demonstration purposes. Automated testing must be put in place to test all documented functionality of your solution. All REST endpoints and/or VCert functions used by the solution must be documented and provided to Venafi. These will be used internally by Venafi to track which features & functions are being used most by developers and end users. They will not be shared publicly. Do you have feedback about the certification process? We've tried to make the certification process as simple and pain free as possible, but we're always looking to make it better. If you have any suggestions or feedback to improve the process, we'd love to hear them !","title":"Certification Requirements"},{"location":"Developers/Certification/TLS-Protect-Cloud/3-tlsp-certification-FAQs/","text":"Resources & FAQs \u00b6 Below are some useful resources and frequently asked questions from previous developers who've already completed the certification process: Resources \u00b6 Account Required Some of the resources on this page will require a Venafi user account in order to access. Please feel free to create one. If you encounter any issues, please let us know . TLS Protect Cloud API Documentation Example Solution Repo - This provides a thorough example of how the README.md file should be created to be most impactful for Venafi users. Rather than creating Word documents or PDFs, all documentation should start in Markdown, which provides better version control and can then be easily translated to other formats as needed. Venafi Marketplace - Explore the Marketplace to get an idea about some of the existing solutions to Venafi. FAQs \u00b6 Will my solution be listed on the Venafi Marketplace if I don't pursue official certification? ANSWER: Your solution may still be listed if it works with TLS Protect Datacenter , but it will not be listed as officially compatible with TLS Protect Cloud and will not have the official badge of certification. How long will the certification process take? ANSWER: The certification process itself moves relatively quickly - you've already done the time-consuming part building and documenting the solution. Once you've submitted a Request for Certification, it typically takes only a couple of days to schedule the final milestone demo (a short session for you to demonstrate the described functionality to the Venafi Ecosystem team). Will I receive any marketing assets that I can use on my own websites and collateral? ANSWER: Yes, definitely! We love seeing Venafi certification badges out in the wild. Official badges will be provided upon completion of the certification process. How often will I be required to re-certify my solution? ANSWER: For now, we'd like you to re-certify for any Major release or feature addition/enhancement. Minor releases don't require re-certification. If you've just released a new Major version or added a new feature, please submit a new certification request. Submit Certification Request","title":"Resources & FAQs"},{"location":"Developers/Certification/TLS-Protect-Cloud/3-tlsp-certification-FAQs/#resources-faqs","text":"Below are some useful resources and frequently asked questions from previous developers who've already completed the certification process:","title":"Resources & FAQs"},{"location":"Developers/Certification/TLS-Protect-Cloud/3-tlsp-certification-FAQs/#resources","text":"Account Required Some of the resources on this page will require a Venafi user account in order to access. Please feel free to create one. If you encounter any issues, please let us know . TLS Protect Cloud API Documentation Example Solution Repo - This provides a thorough example of how the README.md file should be created to be most impactful for Venafi users. Rather than creating Word documents or PDFs, all documentation should start in Markdown, which provides better version control and can then be easily translated to other formats as needed. Venafi Marketplace - Explore the Marketplace to get an idea about some of the existing solutions to Venafi.","title":"Resources"},{"location":"Developers/Certification/TLS-Protect-Cloud/3-tlsp-certification-FAQs/#faqs","text":"Will my solution be listed on the Venafi Marketplace if I don't pursue official certification? ANSWER: Your solution may still be listed if it works with TLS Protect Datacenter , but it will not be listed as officially compatible with TLS Protect Cloud and will not have the official badge of certification. How long will the certification process take? ANSWER: The certification process itself moves relatively quickly - you've already done the time-consuming part building and documenting the solution. Once you've submitted a Request for Certification, it typically takes only a couple of days to schedule the final milestone demo (a short session for you to demonstrate the described functionality to the Venafi Ecosystem team). Will I receive any marketing assets that I can use on my own websites and collateral? ANSWER: Yes, definitely! We love seeing Venafi certification badges out in the wild. Official badges will be provided upon completion of the certification process. How often will I be required to re-certify my solution? ANSWER: For now, we'd like you to re-certify for any Major release or feature addition/enhancement. Minor releases don't require re-certification. If you've just released a new Major version or added a new feature, please submit a new certification request. Submit Certification Request","title":"FAQs"},{"location":"Developers/Certification/TLS-Protect-Cloud/4-tlsp-certification-submit/","text":"Submit Your Solution \u00b6 Once your solution has been built and been tested internally by your team, you've produced any accompanying documentation and you've recorded a short video demo walking through each supported function of your solution, your solution is ready for certification! Submit Certification Request","title":"Submit Your Solution"},{"location":"Developers/Certification/TLS-Protect-Cloud/4-tlsp-certification-submit/#submit-your-solution","text":"Once your solution has been built and been tested internally by your team, you've produced any accompanying documentation and you've recorded a short video demo walking through each supported function of your solution, your solution is ready for certification! Submit Certification Request","title":"Submit Your Solution"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/","text":"Certification - TLS Protect For Kubernetes \u00b6 This page is meant to be your home base throughout the certification process, so please feel free to jump around, read ahead, bookmark and come back to it as needed. Ready to certify? If you've already completed your solution, understand and meet the necessary requirements and are ready to submit a request for Certification, you can start here. Introduction \u00b6 As a TLS Protect For Kubernetes Certified solution, Venafi users have an extra level of confidence that your solution was designed with their best interests at the forefront. For that reason, certified solutions see more adoption from our mutual users. When building a solution to TLS Protect For Kubernetes, one desired outcome should be official certification. Official certification is the first step to listing the solution on the Venafi Marketplace , which is the #1 way end users discover and deploy solutions. Certification is the only way that an solution will be listed on the Venafi Marketplace as compatible with TLS Protect For Kubernetes. The TLS Protect For Kubernetes Certification Program is still evolving and so some specifics about the following requirements are subject to change. Ample notice will be given to any developers of an existing certified solution, ensuring plenty of time to make any necessary updates to maintain certification. The following requirements are applicable to every TLS Protect For Kubernetes solution, however there may be additional, unlisted requirements depending on the specific use case of the solution. There will be solutions and use cases that come forward that are totally new and unique from every solution that has gone through the certification process - and that's GREAT! It means machine identity management is continuing to evolve and see continued adoption. We're all in this together In cases where the Venafi team requests additional requirements be met, we will work with you to determine what success looks like and do our best to provide any Tools/guidance necessary to reach certification. Technical Certification vs. Partner Program \u00b6 The technical certification process is not to be confused with Venafi Partnership, though the two are related. The best way to think about it would be \"Packaging\" vs. \"Marketing\". Packaging \u00b6 The final step of the TLS Protect For Kubernetes certification process will be Packaging - deciding how end users will deploy and interact with your solution. In order for end users to discover the solution and establish a strong user base, the packaging of the solution should be polished and easy to understand. Use of company logos, iconography, product names, marketing copy, etc. will all help users quickly identify your solution in the growing Venafi Marketplace . Marketing \u00b6 Marketing , on the other hand, focuses on bringing attention to a fully packaged & published solution. Once the solution has been certified and the initial Marketplace Listing has been created, the next logical step would be an official partnership with Venafi, which will also engage the Venafi Marketing team to start making some noise about the new solution available to Venafi users.","title":"TLS Protect For Kubernetes"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/#certification-tls-protect-for-kubernetes","text":"This page is meant to be your home base throughout the certification process, so please feel free to jump around, read ahead, bookmark and come back to it as needed. Ready to certify? If you've already completed your solution, understand and meet the necessary requirements and are ready to submit a request for Certification, you can start here.","title":"Certification - TLS Protect For Kubernetes"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/#introduction","text":"As a TLS Protect For Kubernetes Certified solution, Venafi users have an extra level of confidence that your solution was designed with their best interests at the forefront. For that reason, certified solutions see more adoption from our mutual users. When building a solution to TLS Protect For Kubernetes, one desired outcome should be official certification. Official certification is the first step to listing the solution on the Venafi Marketplace , which is the #1 way end users discover and deploy solutions. Certification is the only way that an solution will be listed on the Venafi Marketplace as compatible with TLS Protect For Kubernetes. The TLS Protect For Kubernetes Certification Program is still evolving and so some specifics about the following requirements are subject to change. Ample notice will be given to any developers of an existing certified solution, ensuring plenty of time to make any necessary updates to maintain certification. The following requirements are applicable to every TLS Protect For Kubernetes solution, however there may be additional, unlisted requirements depending on the specific use case of the solution. There will be solutions and use cases that come forward that are totally new and unique from every solution that has gone through the certification process - and that's GREAT! It means machine identity management is continuing to evolve and see continued adoption. We're all in this together In cases where the Venafi team requests additional requirements be met, we will work with you to determine what success looks like and do our best to provide any Tools/guidance necessary to reach certification.","title":"Introduction"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/#technical-certification-vs-partner-program","text":"The technical certification process is not to be confused with Venafi Partnership, though the two are related. The best way to think about it would be \"Packaging\" vs. \"Marketing\".","title":"Technical Certification vs. Partner Program"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/#packaging","text":"The final step of the TLS Protect For Kubernetes certification process will be Packaging - deciding how end users will deploy and interact with your solution. In order for end users to discover the solution and establish a strong user base, the packaging of the solution should be polished and easy to understand. Use of company logos, iconography, product names, marketing copy, etc. will all help users quickly identify your solution in the growing Venafi Marketplace .","title":"Packaging"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/#marketing","text":"Marketing , on the other hand, focuses on bringing attention to a fully packaged & published solution. Once the solution has been certified and the initial Marketplace Listing has been created, the next logical step would be an official partnership with Venafi, which will also engage the Venafi Marketing team to start making some noise about the new solution available to Venafi users.","title":"Marketing"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/2-tlspk-certification-reqs/","text":"Requirements \u00b6 There are currently two levels of certification for TLS Protect For Kubernetes solutions, Foundation Certification and Advanced Certification . It's our hope that every developer strives for the most comprehensive solution, but understand that isn't always possible due to resource and/or time constraints. The purpose of creating multiple levels of certification is two-fold: It provides a lower barrier to entry for smaller organizations and individual contributors It provides an opportunity for developers to further differentiate their solution by providing additional collateral that will help end users get started #fastsecure when using the solution. Meeting the requirements for Foundation Certification should be the first point of focus for any new developer. These requirements have been designed to create a simple pathway for developers to get a listing onto the Venafi Marketplace, while ensuring a consistent, stable experience for all TLS Protect For Kubernetes end users. All TLS Protect For Kubernetes solutions that are published on the Venafi Marketplace are required to meet the requirements for Foundation Certification. Advanced Certification provides a means to differentiate an solution that goes above & beyond the requirements specified above. Functionally, both Foundation Certification and Advanced Certification have the same technical requirements. The difference between the two levels is really about end user enablement and ongoing testing to ensure the solution remains fully functional. From an end user's perspective, generally the more collateral available to be consumed, the less likely end users are to have questions that might block them from testing and ultimately utilizing the solution. The easier it is to deploy and test the solution, the more widely adopted that solution becomes throughout the user base. More users generate more feedback and ideas, and the solution becomes more robust as a result. Certification Requirements \u00b6 Foundation Advanced The description of the solution is an accurate representation of functionality. The solution doesn't interfere with TLS Protect For Kubernetes native functionality or performance. The solution was developed with overall security best practices in mind and makes no attempts to harvest user data. The solution uses generally available interfaces to interact with TLS Protect For Kubernetes (jsctl, REST API, etc.). Accompanying documentation must be packaged with the solution and should include any necessary configuration instructions as well as clear usage examples. Templates are provided for this purpose. The support model is clearly defined for all user types. A demonstration of all documented functionality must be scheduled & completed with the Venafi Ecosystem team. Everything listed in the Foundation Certification Requirements section tab be completed, in addition to the following: A 5-10 minute technical demonstration video covering any initial configuration and typical usage examples must be available online. When necessary, and if possible/feasible for the solution, a test instance or account will be provided to the Venafi Ecosystem team for internal testing and demonstration purposes. Automated testing must be put in place to test all documented functionality of your solution. All REST endpoints and/or jsctl functions used by the solution must be documented and provided to Venafi. These will be used internally by Venafi to track which features & functions are being used most by developers and end users. They will not be shared publicly. Do you have feedback about the certification process? We've tried to make the certification process as simple and pain free as possible, but we're always looking to make it better. If you have any suggestions or feedback to improve the process, we'd love to hear them !","title":"Requirements"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/2-tlspk-certification-reqs/#requirements","text":"There are currently two levels of certification for TLS Protect For Kubernetes solutions, Foundation Certification and Advanced Certification . It's our hope that every developer strives for the most comprehensive solution, but understand that isn't always possible due to resource and/or time constraints. The purpose of creating multiple levels of certification is two-fold: It provides a lower barrier to entry for smaller organizations and individual contributors It provides an opportunity for developers to further differentiate their solution by providing additional collateral that will help end users get started #fastsecure when using the solution. Meeting the requirements for Foundation Certification should be the first point of focus for any new developer. These requirements have been designed to create a simple pathway for developers to get a listing onto the Venafi Marketplace, while ensuring a consistent, stable experience for all TLS Protect For Kubernetes end users. All TLS Protect For Kubernetes solutions that are published on the Venafi Marketplace are required to meet the requirements for Foundation Certification. Advanced Certification provides a means to differentiate an solution that goes above & beyond the requirements specified above. Functionally, both Foundation Certification and Advanced Certification have the same technical requirements. The difference between the two levels is really about end user enablement and ongoing testing to ensure the solution remains fully functional. From an end user's perspective, generally the more collateral available to be consumed, the less likely end users are to have questions that might block them from testing and ultimately utilizing the solution. The easier it is to deploy and test the solution, the more widely adopted that solution becomes throughout the user base. More users generate more feedback and ideas, and the solution becomes more robust as a result.","title":"Requirements"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/2-tlspk-certification-reqs/#certification-requirements","text":"Foundation Advanced The description of the solution is an accurate representation of functionality. The solution doesn't interfere with TLS Protect For Kubernetes native functionality or performance. The solution was developed with overall security best practices in mind and makes no attempts to harvest user data. The solution uses generally available interfaces to interact with TLS Protect For Kubernetes (jsctl, REST API, etc.). Accompanying documentation must be packaged with the solution and should include any necessary configuration instructions as well as clear usage examples. Templates are provided for this purpose. The support model is clearly defined for all user types. A demonstration of all documented functionality must be scheduled & completed with the Venafi Ecosystem team. Everything listed in the Foundation Certification Requirements section tab be completed, in addition to the following: A 5-10 minute technical demonstration video covering any initial configuration and typical usage examples must be available online. When necessary, and if possible/feasible for the solution, a test instance or account will be provided to the Venafi Ecosystem team for internal testing and demonstration purposes. Automated testing must be put in place to test all documented functionality of your solution. All REST endpoints and/or jsctl functions used by the solution must be documented and provided to Venafi. These will be used internally by Venafi to track which features & functions are being used most by developers and end users. They will not be shared publicly. Do you have feedback about the certification process? We've tried to make the certification process as simple and pain free as possible, but we're always looking to make it better. If you have any suggestions or feedback to improve the process, we'd love to hear them !","title":"Certification Requirements"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/3-tlspk-certification-FAQs/","text":"Resources & FAQs \u00b6 Below are some useful resources and frequently asked questions from previous developers who've already completed the certification process: Resources \u00b6 Example Solution Repo - This provides a thorough example of how the README.md file should be created to be most impactful for Venafi users. Rather than creating Word documents or PDFs, all documentation should start in Markdown, which provides better version control and can then be easily translated to other formats as needed. TLS Protect For Kubernetes API Documentation Venafi Marketplace - Explore the Marketplace to get an idea about some of the existing solutions to Venafi. FAQs \u00b6 Will my solution be listed on the Venafi Marketplace if I don't pursue official certification? ANSWER: Your solution may still be listed, but it will not be listed as officially compatible with TLS Protect For Kubernetes and will not have the official badge of certification. How long will the certification process take? ANSWER: The certification process itself moves relatively quickly - you've already done the time-consuming part building and documenting the solution. Once you've submitted a Request for Certification, it typically takes only a couple of days to schedule the final milestone demo (a short session for you to demonstrate the described functionality to the Venafi Ecosystem team). Will I receive any marketing assets that I can use on my own websites and collateral? ANSWER: Yes, definitely! We love seeing Venafi certification badges out in the wild. Official badges will be provided upon completion of the certification process. How often will I be required to re-certify my solution? ANSWER: For now, we'd like you to re-certify for any Major release or feature addition/enhancement. Minor releases don't require re-certification. If you've just released a new Major version or added a new feature, please submit a new certification request. Submit Certification Request","title":"Resources & FAQs"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/3-tlspk-certification-FAQs/#resources-faqs","text":"Below are some useful resources and frequently asked questions from previous developers who've already completed the certification process:","title":"Resources & FAQs"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/3-tlspk-certification-FAQs/#resources","text":"Example Solution Repo - This provides a thorough example of how the README.md file should be created to be most impactful for Venafi users. Rather than creating Word documents or PDFs, all documentation should start in Markdown, which provides better version control and can then be easily translated to other formats as needed. TLS Protect For Kubernetes API Documentation Venafi Marketplace - Explore the Marketplace to get an idea about some of the existing solutions to Venafi.","title":"Resources"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/3-tlspk-certification-FAQs/#faqs","text":"Will my solution be listed on the Venafi Marketplace if I don't pursue official certification? ANSWER: Your solution may still be listed, but it will not be listed as officially compatible with TLS Protect For Kubernetes and will not have the official badge of certification. How long will the certification process take? ANSWER: The certification process itself moves relatively quickly - you've already done the time-consuming part building and documenting the solution. Once you've submitted a Request for Certification, it typically takes only a couple of days to schedule the final milestone demo (a short session for you to demonstrate the described functionality to the Venafi Ecosystem team). Will I receive any marketing assets that I can use on my own websites and collateral? ANSWER: Yes, definitely! We love seeing Venafi certification badges out in the wild. Official badges will be provided upon completion of the certification process. How often will I be required to re-certify my solution? ANSWER: For now, we'd like you to re-certify for any Major release or feature addition/enhancement. Minor releases don't require re-certification. If you've just released a new Major version or added a new feature, please submit a new certification request. Submit Certification Request","title":"FAQs"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/4-tlspk-certification-submit/","text":"Submit Your Solution \u00b6 Once your solution has been built and been tested internally by your team, you've produced any accompanying documentation and you've recorded a short video demo walking through each supported function of your solution, your solution is ready for certification! Submit Certification Request","title":"Submit Your Solution"},{"location":"Developers/Certification/TLS-Protect-For-Kubernetes/4-tlspk-certification-submit/#submit-your-solution","text":"Once your solution has been built and been tested internally by your team, you've produced any accompanying documentation and you've recorded a short video demo walking through each supported function of your solution, your solution is ready for certification! Submit Certification Request","title":"Submit Your Solution"},{"location":"Developers/Design-Patterns/general-guidelines/","text":"General Guidelines & Best Practices \u00b6 The following guidelines apply generically to all solutions to Venafi, regardless of solution type, and should be referenced as the solution is developed & tested, and as new features or enhancements are added. Naming Conventions \u00b6 A standard naming convention should be adopted to avoid any collisions when objects (applications, certificates, devices, etc.) are created. Collisions can occur when the name you define already exists in Venafi. You can use the same prefix or suffix, and then add something unique to the name. Debug Logging \u00b6 It's strongly encouraged to build in debug logging that can be enabled by end users when troubleshooting issues in their environments.","title":"Design Patterns"},{"location":"Developers/Design-Patterns/general-guidelines/#general-guidelines-best-practices","text":"The following guidelines apply generically to all solutions to Venafi, regardless of solution type, and should be referenced as the solution is developed & tested, and as new features or enhancements are added.","title":"General Guidelines & Best Practices"},{"location":"Developers/Design-Patterns/general-guidelines/#naming-conventions","text":"A standard naming convention should be adopted to avoid any collisions when objects (applications, certificates, devices, etc.) are created. Collisions can occur when the name you define already exists in Venafi. You can use the same prefix or suffix, and then add something unique to the name.","title":"Naming Conventions"},{"location":"Developers/Design-Patterns/general-guidelines/#debug-logging","text":"It's strongly encouraged to build in debug logging that can be enabled by end users when troubleshooting issues in their environments.","title":"Debug Logging"},{"location":"Developers/Design-Patterns/Cloud-WAF/0-intro-cloud-waf/","text":"Cloud WAF \u00b6 This page has moved! Design patterns for TLS Protect have been moved to Venafi Dev Central. Please visit the Cloud WAF page on Dev Central for the latest information.","title":"Cloud WAF"},{"location":"Developers/Design-Patterns/Cloud-WAF/0-intro-cloud-waf/#cloud-waf","text":"This page has moved! Design patterns for TLS Protect have been moved to Venafi Dev Central. Please visit the Cloud WAF page on Dev Central for the latest information.","title":"Cloud WAF"},{"location":"Developers/Design-Patterns/Ingress/0-intro-ingress/","text":"Ingress \u00b6 Ingress is the term used for a native Kubernetes resource that details the external routes into a cluster. Ingress may provide load balancing, TLS termination, intelligent routing and API Gateway functionality. cert-manager integrates with Ingress objects to fulfill their role in securing your Kubernetes clusters. TLS Protect For Kubernetes, which provides first-class support for Ingress objects, includes an enterprise-hardened version of cert-manager and capabilities to support machine identities in the enterprise. Introduction \u00b6 Kubernetes is a platform for building platforms which helps companies modernize with speed and agility . It has a reduced set of opinions about how business demands are fulfilled. This creates technological voids which the Kuberenetes community strives to fill. One such area is Ingress Controllers , for which the community has provided many options . Design Pattern: Ingress The principal concern of any ingress controller is to accept traffic from outside a given network space and intelligently pass that traffic on to an internally defined resource. This design pattern focuses on the use case of securely leveraging machine identities for use via ingress controllers. It highlights the need for automation to ensure that once your solution is deployed it stays there, proactively securing workloads long into the future. Before you begin, it's important to understand the \"what\" and \"why\" of Ingress . What is it? \u00b6 Ingress is a native Kubernetes construct. Objects of this type represent lines of communication from outside a cluster (which could mean the internet) to workloads running inside this cluster. Ingress objects bring network intelligence to multi-purpose proxy servers in the form of routing rules. Without the ability to span this divide Kubernetes would be isolated from the outside world and limited to running non-interactive workloads such as batch jobs. Whilst Ingress is native to Kubernetes, Ingress Controllers are not. An Ingress object can exist, but without an associated controller to respond, it will remain dormant - somewhat like a car without a driver. Selecting a suitable Ingress Controller is a choice each cluster intends for you to make. Why is it necessary? \u00b6 In addition to routing rules, Ingress Controllers also provide enhanced security which, given the importance of machine identities, should be your primary concern. The internet was originally envisioned as a medium for sharing information, however the modern world demands that information should be much better protected. To meet these demands we have seen the steady rise of HTTPS to the point where modern browsers baulk at the use of plain old HTTP so Transport Layer Security (TLS), which enables HTTPS, is now a mandatory requirement. Henceforth you need to enforce the security of your data in transit . Doing so with an Ingress Controller moves TLS termination closer to your workloads thereby helping to prevent misuse and compromise . Organizations use machine identities to provide end-to-end security of data sent between running processes with the TLS cryptographic protocol. The use of X.509 certificates and HTTPS are the most common manifestation of this. Those machine identities are sometimes installed at the application endpoint - as a layer of configuration inside your container images. Cloud native principles such as 12 factor dependencies may convince you this is the right choice. It's certainly convenient but this approach has a major flaw in that machine identities eventually expire so they must not be treated as static dependencies of your workloads . This matters because when active machine identities expire or become unavailable, outages happen. Outages Workloads can become unavailable for many reasons and any such event can be described as an outage . When you choose to secure your workloads , you introduce an additional failure point, specifically the machine identity itself. This is because machine identities are designed to expire after some predefined duration. When machine identities expire they stop working and the workloads they protect become unavailable. A likely outcome of failing to mitigate against outages is negative impact to brand reputation and lost revenue. Automation using the Machine Identity Management Control Plane is a key defense against outages. There are further limitations that stem from the use of containers with pre-baked security measures but the example above represents one that can be effectively tackled through the use of an Ingress. FAQs \u00b6 Before you proceed there may be a few initial questions that need addressing, for example: \"What problem will you solve?\" TLS Protect For Kubernetes users need machine identities that are trusted not just between workloads located on a single cluster using mTLS but also between public-facing workloads and other external clients such as end-user browsers. \"What will the outcome be?\" Users of your public-facing solution can stop outages caused by expiring machine identities. This builds customer trust and loyalty. \"What will you need to deliver?\" You solution will be in the form of Kubernetes controllers and CRDs . Your images will be sourced from a public container registry and installation will be achieved via a Helm chart. \"How will your solution be used?\" Automation via your Ingress controller will be initiated through the use of routes encoded within native Kubernetes Ingress objects. There may be a requirement for supplementary CRDs to configure your controller. \"What about authentication and authorization?\" Whilst it is not a requirement for your solution to handle authentication and authorization, there are Ingress controllers out there which do. If you choose this to provide this, we recommend you integrate with existing OpenID Connect (OIDC) identity providers such as Okta and Ping Identity . \"Why will you want to certify your solution?\" Hop over to our certification section for TLS Protect For Kubernetes to find out more If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.","title":"Ingress"},{"location":"Developers/Design-Patterns/Ingress/0-intro-ingress/#ingress","text":"Ingress is the term used for a native Kubernetes resource that details the external routes into a cluster. Ingress may provide load balancing, TLS termination, intelligent routing and API Gateway functionality. cert-manager integrates with Ingress objects to fulfill their role in securing your Kubernetes clusters. TLS Protect For Kubernetes, which provides first-class support for Ingress objects, includes an enterprise-hardened version of cert-manager and capabilities to support machine identities in the enterprise.","title":"Ingress"},{"location":"Developers/Design-Patterns/Ingress/0-intro-ingress/#introduction","text":"Kubernetes is a platform for building platforms which helps companies modernize with speed and agility . It has a reduced set of opinions about how business demands are fulfilled. This creates technological voids which the Kuberenetes community strives to fill. One such area is Ingress Controllers , for which the community has provided many options . Design Pattern: Ingress The principal concern of any ingress controller is to accept traffic from outside a given network space and intelligently pass that traffic on to an internally defined resource. This design pattern focuses on the use case of securely leveraging machine identities for use via ingress controllers. It highlights the need for automation to ensure that once your solution is deployed it stays there, proactively securing workloads long into the future. Before you begin, it's important to understand the \"what\" and \"why\" of Ingress .","title":"Introduction"},{"location":"Developers/Design-Patterns/Ingress/0-intro-ingress/#what-is-it","text":"Ingress is a native Kubernetes construct. Objects of this type represent lines of communication from outside a cluster (which could mean the internet) to workloads running inside this cluster. Ingress objects bring network intelligence to multi-purpose proxy servers in the form of routing rules. Without the ability to span this divide Kubernetes would be isolated from the outside world and limited to running non-interactive workloads such as batch jobs. Whilst Ingress is native to Kubernetes, Ingress Controllers are not. An Ingress object can exist, but without an associated controller to respond, it will remain dormant - somewhat like a car without a driver. Selecting a suitable Ingress Controller is a choice each cluster intends for you to make.","title":"What is it?"},{"location":"Developers/Design-Patterns/Ingress/0-intro-ingress/#why-is-it-necessary","text":"In addition to routing rules, Ingress Controllers also provide enhanced security which, given the importance of machine identities, should be your primary concern. The internet was originally envisioned as a medium for sharing information, however the modern world demands that information should be much better protected. To meet these demands we have seen the steady rise of HTTPS to the point where modern browsers baulk at the use of plain old HTTP so Transport Layer Security (TLS), which enables HTTPS, is now a mandatory requirement. Henceforth you need to enforce the security of your data in transit . Doing so with an Ingress Controller moves TLS termination closer to your workloads thereby helping to prevent misuse and compromise . Organizations use machine identities to provide end-to-end security of data sent between running processes with the TLS cryptographic protocol. The use of X.509 certificates and HTTPS are the most common manifestation of this. Those machine identities are sometimes installed at the application endpoint - as a layer of configuration inside your container images. Cloud native principles such as 12 factor dependencies may convince you this is the right choice. It's certainly convenient but this approach has a major flaw in that machine identities eventually expire so they must not be treated as static dependencies of your workloads . This matters because when active machine identities expire or become unavailable, outages happen. Outages Workloads can become unavailable for many reasons and any such event can be described as an outage . When you choose to secure your workloads , you introduce an additional failure point, specifically the machine identity itself. This is because machine identities are designed to expire after some predefined duration. When machine identities expire they stop working and the workloads they protect become unavailable. A likely outcome of failing to mitigate against outages is negative impact to brand reputation and lost revenue. Automation using the Machine Identity Management Control Plane is a key defense against outages. There are further limitations that stem from the use of containers with pre-baked security measures but the example above represents one that can be effectively tackled through the use of an Ingress.","title":"Why is it necessary?"},{"location":"Developers/Design-Patterns/Ingress/0-intro-ingress/#faqs","text":"Before you proceed there may be a few initial questions that need addressing, for example: \"What problem will you solve?\" TLS Protect For Kubernetes users need machine identities that are trusted not just between workloads located on a single cluster using mTLS but also between public-facing workloads and other external clients such as end-user browsers. \"What will the outcome be?\" Users of your public-facing solution can stop outages caused by expiring machine identities. This builds customer trust and loyalty. \"What will you need to deliver?\" You solution will be in the form of Kubernetes controllers and CRDs . Your images will be sourced from a public container registry and installation will be achieved via a Helm chart. \"How will your solution be used?\" Automation via your Ingress controller will be initiated through the use of routes encoded within native Kubernetes Ingress objects. There may be a requirement for supplementary CRDs to configure your controller. \"What about authentication and authorization?\" Whilst it is not a requirement for your solution to handle authentication and authorization, there are Ingress controllers out there which do. If you choose this to provide this, we recommend you integrate with existing OpenID Connect (OIDC) identity providers such as Okta and Ping Identity . \"Why will you want to certify your solution?\" Hop over to our certification section for TLS Protect For Kubernetes to find out more If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.","title":"FAQs"},{"location":"Developers/Design-Patterns/Ingress/1-requirements-ingress/","text":"Requirements and Considerations \u00b6 When developing Ingress solutions for the Machine Identity Management Control Plane , you should always build with the goal of certification in mind. TLS Protect For Kubernetes Certification Certified solutions see increased adoption from users. Find out more! Minimum Requirements \u00b6 The solution must automate the delivery/consumption of any machine identity required to enforce the security of workloads protected by the Ingress Controller . The solution must cope with both the creation and renewal of machine identities. The solution must perform any necessary updates or reconfigurations to bindings/associations attached to the machine identity . The solution must source its machine identities from Kubernetes secrets. Some clarifying remarks on the final point. The use of TLS secrets is commonplace for persisting X.509 certificates but organizations have been known to restrict or even prohibit their use. The Ingress specification mandates the use of secrets when you wish to entrust your Ingress Controller with the task of TLS termination. If this conflicts with your internal policies then the use of Ingress for TLS termination is not an option and you should consider something like the cert-manager csi-driver . The csi-driver solution, which is commonly used to enforce mTLS between workloads , eliminates the use of secrets and necessitates TLS termination closer to your workloads . Focus on UX The best solutions will require little, if any, human interaction after initial configuration. Security Considerations \u00b6 The Kubernetes Ingress specification provides for TLS enforcement on a per routing rule basis, but this security feature is optional . This is somewhat regrettable in light of the modern browser security requirements and your pursuit of zero-trust by default. Security should be uppermost among your concerns. As the developer of a Ingress Controller solution, you will need to: support only Ingress rules with explicit provision for TLS (by default). provide full support for modern OpenID Connect Identity Providers (e.g. Auth0, GitHub, Google, Okta, etc.) These considerations are in addition to any policy enforcement (e.g. minimum cipher strength) applied by TLSPK's approver-policy-enterprise , the Venafi TLS Protect products or upstream Certificate Authorities. Building a Better User Experience \u00b6 The user experience should be as painless as possible and the expectation is that your target product should: Be easy to install, preferably via Helm Be highly available Enable the user to deploy an MVP into your cluster with little or no configuration requirements Provide comprehensive logs for diagnostic purposes Export metrics in the common Prometheus format (e.g. network traffic, latency, error rates, utilization, request counts) Provide complete/appropriate documentation, both online and within CRDs when applicable Conforming to the these requirements will greatly enhance the user experience, providing additional value to teams and organizations. Success Stories \u00b6 Existing solutions that fit within this pattern: Venafi Marketplace Elsewhere NGINX Ingress Pomerium Ingress Kubernetes community","title":"Requirements and Considerations"},{"location":"Developers/Design-Patterns/Ingress/1-requirements-ingress/#requirements-and-considerations","text":"When developing Ingress solutions for the Machine Identity Management Control Plane , you should always build with the goal of certification in mind. TLS Protect For Kubernetes Certification Certified solutions see increased adoption from users. Find out more!","title":"Requirements and Considerations"},{"location":"Developers/Design-Patterns/Ingress/1-requirements-ingress/#minimum-requirements","text":"The solution must automate the delivery/consumption of any machine identity required to enforce the security of workloads protected by the Ingress Controller . The solution must cope with both the creation and renewal of machine identities. The solution must perform any necessary updates or reconfigurations to bindings/associations attached to the machine identity . The solution must source its machine identities from Kubernetes secrets. Some clarifying remarks on the final point. The use of TLS secrets is commonplace for persisting X.509 certificates but organizations have been known to restrict or even prohibit their use. The Ingress specification mandates the use of secrets when you wish to entrust your Ingress Controller with the task of TLS termination. If this conflicts with your internal policies then the use of Ingress for TLS termination is not an option and you should consider something like the cert-manager csi-driver . The csi-driver solution, which is commonly used to enforce mTLS between workloads , eliminates the use of secrets and necessitates TLS termination closer to your workloads . Focus on UX The best solutions will require little, if any, human interaction after initial configuration.","title":"Minimum Requirements"},{"location":"Developers/Design-Patterns/Ingress/1-requirements-ingress/#security-considerations","text":"The Kubernetes Ingress specification provides for TLS enforcement on a per routing rule basis, but this security feature is optional . This is somewhat regrettable in light of the modern browser security requirements and your pursuit of zero-trust by default. Security should be uppermost among your concerns. As the developer of a Ingress Controller solution, you will need to: support only Ingress rules with explicit provision for TLS (by default). provide full support for modern OpenID Connect Identity Providers (e.g. Auth0, GitHub, Google, Okta, etc.) These considerations are in addition to any policy enforcement (e.g. minimum cipher strength) applied by TLSPK's approver-policy-enterprise , the Venafi TLS Protect products or upstream Certificate Authorities.","title":"Security Considerations"},{"location":"Developers/Design-Patterns/Ingress/1-requirements-ingress/#building-a-better-user-experience","text":"The user experience should be as painless as possible and the expectation is that your target product should: Be easy to install, preferably via Helm Be highly available Enable the user to deploy an MVP into your cluster with little or no configuration requirements Provide comprehensive logs for diagnostic purposes Export metrics in the common Prometheus format (e.g. network traffic, latency, error rates, utilization, request counts) Provide complete/appropriate documentation, both online and within CRDs when applicable Conforming to the these requirements will greatly enhance the user experience, providing additional value to teams and organizations.","title":"Building a Better User Experience"},{"location":"Developers/Design-Patterns/Ingress/1-requirements-ingress/#success-stories","text":"Existing solutions that fit within this pattern: Venafi Marketplace Elsewhere NGINX Ingress Pomerium Ingress Kubernetes community","title":"Success Stories"},{"location":"Developers/Design-Patterns/Ingress/2-getting-started-ingress/","text":"Getting Started \u00b6 If you've made it here, you should already have a general understanding about how the Ingress resource relates to machine identities and you're ready to get started developing your Ingress solution. High-level Process \u00b6 Head over to TLS Protect For Kubernetes and select ACCESS YOUR ACCOUNT . Log In to your account or , if you don't already have one, select Sign Up , complete the Terms of Service and follow the on screen prompts. Note : new users will be allocated a organization name made of two randomly selected words (e.g. foxtrot-charlie) which is your private workspace within the SaaS platform. From the TLS Protect For Kubernetes console, select Clusters and CONNECT NEW CLUSTER to familiarize yourself with the steps required to introduce a Kubernetes cluster to your organization. Your choice of Kubernetes distribution is somewhat arbitrary, however you should consider the need to create them repeatedly to enable thorough testing. You should also consider that not all distributions provide native support for Kubernetes services of type LoadBalancer. Try out one or two of the most popular Ingress Controllers to familiarize yourself with their shared behavior and relative strengths. Head over to https://platform.jetstack.io/org/[ORG]/certinventory/cluster/[CLUSTER]/ingresses . This is where you will locate any active Ingress objects in your registered cluster(s). Start building! We highly recommend using Kubebuilder framework to increase your velocity and reduce the complexity inherent in developing any Kubernetes controller. Perform functional testing . Get certified ! Getting Help \u00b6 We think you'll find the following references helpful when developing your solution. Official Kubernetes Ingress Documentation Kubernetes Ingress Explained for Beginners Everything you need to know about Kubebuilder Writing a Kubernetes Operator from Scratch Using Kubebuilder If you are not able to find what you're looking for or you've found other articles/tools that deserve to be included here please post a question to the Developer Forum section of Venafi's Warrior Community or email the Ecosystem team.","title":"Getting Started"},{"location":"Developers/Design-Patterns/Ingress/2-getting-started-ingress/#getting-started","text":"If you've made it here, you should already have a general understanding about how the Ingress resource relates to machine identities and you're ready to get started developing your Ingress solution.","title":"Getting Started"},{"location":"Developers/Design-Patterns/Ingress/2-getting-started-ingress/#high-level-process","text":"Head over to TLS Protect For Kubernetes and select ACCESS YOUR ACCOUNT . Log In to your account or , if you don't already have one, select Sign Up , complete the Terms of Service and follow the on screen prompts. Note : new users will be allocated a organization name made of two randomly selected words (e.g. foxtrot-charlie) which is your private workspace within the SaaS platform. From the TLS Protect For Kubernetes console, select Clusters and CONNECT NEW CLUSTER to familiarize yourself with the steps required to introduce a Kubernetes cluster to your organization. Your choice of Kubernetes distribution is somewhat arbitrary, however you should consider the need to create them repeatedly to enable thorough testing. You should also consider that not all distributions provide native support for Kubernetes services of type LoadBalancer. Try out one or two of the most popular Ingress Controllers to familiarize yourself with their shared behavior and relative strengths. Head over to https://platform.jetstack.io/org/[ORG]/certinventory/cluster/[CLUSTER]/ingresses . This is where you will locate any active Ingress objects in your registered cluster(s). Start building! We highly recommend using Kubebuilder framework to increase your velocity and reduce the complexity inherent in developing any Kubernetes controller. Perform functional testing . Get certified !","title":"High-level Process"},{"location":"Developers/Design-Patterns/Ingress/2-getting-started-ingress/#getting-help","text":"We think you'll find the following references helpful when developing your solution. Official Kubernetes Ingress Documentation Kubernetes Ingress Explained for Beginners Everything you need to know about Kubebuilder Writing a Kubernetes Operator from Scratch Using Kubebuilder If you are not able to find what you're looking for or you've found other articles/tools that deserve to be included here please post a question to the Developer Forum section of Venafi's Warrior Community or email the Ecosystem team.","title":"Getting Help"},{"location":"Developers/Design-Patterns/Ingress/3-functional-testing-ingress/","text":"Functional Testing \u00b6 During development of your Ingress solution, you should keep the following functional tests in mind for this design pattern. The test cases listed below are directly related to the requirements and considerations outlined for this use case. What is functional testing? To summarize Wikipedia : Functional testing is a QA process that sees a \"tester\" run through all documented functionality of a product or, in this case, an integrated solution. It's a great way to uncover bugs, unexpected behaviors and documentation errors. The functional tests documented below are provided as examples. Depending on the supported functionality of the target platform/service you're building for and/or the complexity of your solution, some tests listed below may not be necessary. Similarly, it's possible that you've got such a new or unique solution, that we haven't identified recommended functional tests yet. If you've got suggestions and/or functional tests that helped during your development, please let us know ! Reduce Confirmation Bias It can be extremely helpful, especially when writing documentation that accompanies your solution, to involve others on your team who haven't been involved in the development process. While you might be able to perform all functionality without even referencing the docs, it's possible that a fresh set of eyes will uncover typos or minor omissions that someone directly involved in development might miss. Basic Functionality Tests \u00b6 The following functionality tests should be applicable to every solution targeting this use case. Test Case Description Desired Outcome ING-01 Documentation : Solution should be fully documented Both online and embedded CRD documentation (when applicable) is provided ING-02 Error Handling : Perform an operation which you expect to fail (unsupported key size, missing/incomplete data, etc.) The error will be encountered and a meaningful error message will be presented to the end user and, if applicable, back to Venafi ING-03 CRUD Lifecycle : Standard logic around creation, modification and deletion Ingress and its standard behavioral effects should be observable from within TLS Protect For Kubernetes. Ingress is observed as both updated and subsequently deleted. Exceptions to these outcomes must be justified and documented ING-04 TLS : Support TLS-enabled public routes TLS-enabled Ingress routes are provisioned and observable from within TLS Protect For Kubernetes. Meanwhile, browser can navigate to workload via HTTPS without security warnings ING-05 Certificate Renewed : Renew certificate used as a machine identity Revised expiry date for Ingress machine identity is visible from within TLS Protect For Kubernetes. Ingress reconfiguration is automatically triggered Advanced Functionality Tests \u00b6 Depending on the exact functionality of the target solution, the following tests may or may not be applicable. Test Case Description Desired Outcome ING-101 OpenID Connect : Integrate with OpenID Connect identity providers Alongside machine identities security, your solution should also be able to demonstrate support for Authentication and Authorization","title":"Functional Testing"},{"location":"Developers/Design-Patterns/Ingress/3-functional-testing-ingress/#functional-testing","text":"During development of your Ingress solution, you should keep the following functional tests in mind for this design pattern. The test cases listed below are directly related to the requirements and considerations outlined for this use case. What is functional testing? To summarize Wikipedia : Functional testing is a QA process that sees a \"tester\" run through all documented functionality of a product or, in this case, an integrated solution. It's a great way to uncover bugs, unexpected behaviors and documentation errors. The functional tests documented below are provided as examples. Depending on the supported functionality of the target platform/service you're building for and/or the complexity of your solution, some tests listed below may not be necessary. Similarly, it's possible that you've got such a new or unique solution, that we haven't identified recommended functional tests yet. If you've got suggestions and/or functional tests that helped during your development, please let us know ! Reduce Confirmation Bias It can be extremely helpful, especially when writing documentation that accompanies your solution, to involve others on your team who haven't been involved in the development process. While you might be able to perform all functionality without even referencing the docs, it's possible that a fresh set of eyes will uncover typos or minor omissions that someone directly involved in development might miss.","title":"Functional Testing"},{"location":"Developers/Design-Patterns/Ingress/3-functional-testing-ingress/#basic-functionality-tests","text":"The following functionality tests should be applicable to every solution targeting this use case.","title":"Basic Functionality Tests"},{"location":"Developers/Design-Patterns/Ingress/3-functional-testing-ingress/#advanced-functionality-tests","text":"Depending on the exact functionality of the target solution, the following tests may or may not be applicable.","title":"Advanced Functionality Tests"},{"location":"Developers/Design-Patterns/Issuer/0-intro-issuer/","text":"Issuer \u00b6 Issuer is a capability of cert-manager enabling integration with machine identity providers. These providers are typically Certificate Authorities which publish digital certificates to secure communication between workloads . cert-manager is a critical component in the fight to secure your Kubernetes clusters, helping companies modernize with speed and agility . TLS Protect For Kubernetes includes an enterprise-hardened version of cert-manager alongside extensions to support and manage machine identities in the enterprise. Introduction \u00b6 The chapter on Ingress explains how Kubernetes is broadly unopinionated about the tools you use to fulfill your business demands, such as how you ensure the security of your workloads . The CNCF's move to accept cert-manager as an incubating project solidifies its reputation as the de-facto Kubernetes solution for stopping outages caused by TLS certificate expiry. Design Pattern: Issuer This design pattern focuses on the development of bespoke Issuers for cert-manager. The principal concern of any Issuer is to supervise the creation and renewal of machine identities. This pattern highlights the need to automate everywhere , ensuring that once your solution is deployed it remains in place, proactively securing workloads long into the future. Before you begin, it's important to understand the \"what\" and \"why\" of Issuers in the context of Kubernetes. What is it? \u00b6 The Issuer capability in cert-manager extends the Kubernetes API, abstracting away the complexity of machine identity providers inside your clusters. Each Issuer object represents a provider capable of signing and issuing machine identities, typically in the form of X.509 certificates. These providers could be digital security companies you already know and trust, non-profit organizations or just some well-known devices inside your data center. Each provider brings its own strengths and consumer adoption is determined by various factor such as organizational policy, existing infrastructure, business relationships, individual choice and the task at hand. In a Kubernetes architecture which prevents misuse and compromise , use of a cert-manager Issuer is a mandatory requirement. Why is it necessary? \u00b6 The following diagram is taken from the cert-manager documentation homepage . Native Issuer support in cert-manager is currently limited to the machine identity providers shown above. As a developer who needs to extend the reach of cert-manager to provide support for an alternate machine identity provider, this design pattern is for you. FAQs \u00b6 Before you proceed there may be a few initial questions that need addressing, for example: \"What problem will you solve?\" TLS Protect For Kubernetes users need to provide their clusters with a robust mechanism for delivery of machine identities from your CA's. \"What will the outcome be?\" Automated delivery of machine identities from your CA to your Kubernetes clusters and a reduction in outages due to certificate expiry. \"What will you need to deliver?\" You solution will be in the form of Kubernetes controllers and CRDs . Your images will be sourced from a public container registry and installation will be achieved via a Helm chart. \"How will your solution be used?\" Automation via your issuer will be initiated through the use of declarative references inside cert-manager objects. \"What about authentication and authorization?\" From the perspective of cert-manager there will be zero authentication and authorization requirements, but it will likely be a different story from the perspective of your machine identity provider. You may choose to consult with your machine identity provider to ensure that their own best practices are adhered to. \"Why will you want to certify your solution?\" Hop over to our certification section for TLS Protect For Kubernetes to find out more If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.","title":"Issuer"},{"location":"Developers/Design-Patterns/Issuer/0-intro-issuer/#issuer","text":"Issuer is a capability of cert-manager enabling integration with machine identity providers. These providers are typically Certificate Authorities which publish digital certificates to secure communication between workloads . cert-manager is a critical component in the fight to secure your Kubernetes clusters, helping companies modernize with speed and agility . TLS Protect For Kubernetes includes an enterprise-hardened version of cert-manager alongside extensions to support and manage machine identities in the enterprise.","title":"Issuer"},{"location":"Developers/Design-Patterns/Issuer/0-intro-issuer/#introduction","text":"The chapter on Ingress explains how Kubernetes is broadly unopinionated about the tools you use to fulfill your business demands, such as how you ensure the security of your workloads . The CNCF's move to accept cert-manager as an incubating project solidifies its reputation as the de-facto Kubernetes solution for stopping outages caused by TLS certificate expiry. Design Pattern: Issuer This design pattern focuses on the development of bespoke Issuers for cert-manager. The principal concern of any Issuer is to supervise the creation and renewal of machine identities. This pattern highlights the need to automate everywhere , ensuring that once your solution is deployed it remains in place, proactively securing workloads long into the future. Before you begin, it's important to understand the \"what\" and \"why\" of Issuers in the context of Kubernetes.","title":"Introduction"},{"location":"Developers/Design-Patterns/Issuer/0-intro-issuer/#what-is-it","text":"The Issuer capability in cert-manager extends the Kubernetes API, abstracting away the complexity of machine identity providers inside your clusters. Each Issuer object represents a provider capable of signing and issuing machine identities, typically in the form of X.509 certificates. These providers could be digital security companies you already know and trust, non-profit organizations or just some well-known devices inside your data center. Each provider brings its own strengths and consumer adoption is determined by various factor such as organizational policy, existing infrastructure, business relationships, individual choice and the task at hand. In a Kubernetes architecture which prevents misuse and compromise , use of a cert-manager Issuer is a mandatory requirement.","title":"What is it?"},{"location":"Developers/Design-Patterns/Issuer/0-intro-issuer/#why-is-it-necessary","text":"The following diagram is taken from the cert-manager documentation homepage . Native Issuer support in cert-manager is currently limited to the machine identity providers shown above. As a developer who needs to extend the reach of cert-manager to provide support for an alternate machine identity provider, this design pattern is for you.","title":"Why is it necessary?"},{"location":"Developers/Design-Patterns/Issuer/0-intro-issuer/#faqs","text":"Before you proceed there may be a few initial questions that need addressing, for example: \"What problem will you solve?\" TLS Protect For Kubernetes users need to provide their clusters with a robust mechanism for delivery of machine identities from your CA's. \"What will the outcome be?\" Automated delivery of machine identities from your CA to your Kubernetes clusters and a reduction in outages due to certificate expiry. \"What will you need to deliver?\" You solution will be in the form of Kubernetes controllers and CRDs . Your images will be sourced from a public container registry and installation will be achieved via a Helm chart. \"How will your solution be used?\" Automation via your issuer will be initiated through the use of declarative references inside cert-manager objects. \"What about authentication and authorization?\" From the perspective of cert-manager there will be zero authentication and authorization requirements, but it will likely be a different story from the perspective of your machine identity provider. You may choose to consult with your machine identity provider to ensure that their own best practices are adhered to. \"Why will you want to certify your solution?\" Hop over to our certification section for TLS Protect For Kubernetes to find out more If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.","title":"FAQs"},{"location":"Developers/Design-Patterns/Issuer/1-requirements-issuer/","text":"Requirements and Considerations \u00b6 When developing Issuer solutions for the Machine Identity Management Control Plane , you should always build with the goal of certification in mind. TLS Protect For Kubernetes Certification Certified solutions see increased adoption from users. Find out more! Minimum Requirements \u00b6 The solution must be open source and its container images published to publicly available image registries. The solution must automate the production of machine identities from the underlying provider to enforce the security of traffic between workloads . The solution will expect cert-manager to hand CertificateRequest objects to it and be able to, directly or indirectly, produce a machine identity . Security Considerations \u00b6 The extent of your security considerations is somewhat governed by the intention of your Issuer. As the developer of an Issuer solution, you will need to determine if your underlying Certificate Authority (CA) could be required to secure internet traffic or not. Internal traffic could be deemed to be secure when plain-text communication is eliminated, which is easier to ensure. The requirements for securing internet traffic are likely higher, since your responsibility now extends to cover concerns such as identity and attestation (e.g. \"is this domain owner really who they say they are?\") To clarify, you would find it much easier to build a self-signed Issuer than an Issuer for something like a Certificate Authority where security concerns such as authentication would need to be addressed. Building a Better User Experience \u00b6 The user experience should be as painless as possible and the expectation is that your solution should be: Easy to install, preferably via Helm Able to deploy an MVP into your cluster with little or no configuration requirements Provide comprehensive logs and metrics for diagnostic purposes Provide complete/appropriate documentation online and via CRDs Conforming to the these requirements will greatly enhance the user experience, providing additional value to teams and organizations whilst paving the way to certification of your solution. Success Stories \u00b6 Existing solutions that fit within this pattern: Community Proprietary The cert-manager community provides a collection of open-source External Issuers enabling distribution of machine identities from providers including AWS, Google and Cloudflare. The venafi-enhanced-issuer is provided with TLS Protect For Kubernetes to meet the needs of enterprise customer.","title":"Requirements and Considerations"},{"location":"Developers/Design-Patterns/Issuer/1-requirements-issuer/#requirements-and-considerations","text":"When developing Issuer solutions for the Machine Identity Management Control Plane , you should always build with the goal of certification in mind. TLS Protect For Kubernetes Certification Certified solutions see increased adoption from users. Find out more!","title":"Requirements and Considerations"},{"location":"Developers/Design-Patterns/Issuer/1-requirements-issuer/#minimum-requirements","text":"The solution must be open source and its container images published to publicly available image registries. The solution must automate the production of machine identities from the underlying provider to enforce the security of traffic between workloads . The solution will expect cert-manager to hand CertificateRequest objects to it and be able to, directly or indirectly, produce a machine identity .","title":"Minimum Requirements"},{"location":"Developers/Design-Patterns/Issuer/1-requirements-issuer/#security-considerations","text":"The extent of your security considerations is somewhat governed by the intention of your Issuer. As the developer of an Issuer solution, you will need to determine if your underlying Certificate Authority (CA) could be required to secure internet traffic or not. Internal traffic could be deemed to be secure when plain-text communication is eliminated, which is easier to ensure. The requirements for securing internet traffic are likely higher, since your responsibility now extends to cover concerns such as identity and attestation (e.g. \"is this domain owner really who they say they are?\") To clarify, you would find it much easier to build a self-signed Issuer than an Issuer for something like a Certificate Authority where security concerns such as authentication would need to be addressed.","title":"Security Considerations"},{"location":"Developers/Design-Patterns/Issuer/1-requirements-issuer/#building-a-better-user-experience","text":"The user experience should be as painless as possible and the expectation is that your solution should be: Easy to install, preferably via Helm Able to deploy an MVP into your cluster with little or no configuration requirements Provide comprehensive logs and metrics for diagnostic purposes Provide complete/appropriate documentation online and via CRDs Conforming to the these requirements will greatly enhance the user experience, providing additional value to teams and organizations whilst paving the way to certification of your solution.","title":"Building a Better User Experience"},{"location":"Developers/Design-Patterns/Issuer/1-requirements-issuer/#success-stories","text":"Existing solutions that fit within this pattern: Community Proprietary The cert-manager community provides a collection of open-source External Issuers enabling distribution of machine identities from providers including AWS, Google and Cloudflare. The venafi-enhanced-issuer is provided with TLS Protect For Kubernetes to meet the needs of enterprise customer.","title":"Success Stories"},{"location":"Developers/Design-Patterns/Issuer/2-getting-started-issuer/","text":"Getting Started \u00b6 If you've made it here, you should already have a general understanding about Issuers and machine identities . Now you're ready to get started developing your Issuer solution. Steps \u00b6 Head over to TLS Protect For Kubernetes and select ACCESS YOUR ACCOUNT . Log In to your account or , if you don't already have one, select Sign Up , complete the Terms of Service and follow the on screen prompts. Note : new users will be allocated a organization name made of two randomly selected words (e.g. foxtrot-charlie) which is your private workspace within the SaaS platform. From the TLS Protect For Kubernetes console, select Clusters and CONNECT NEW CLUSTER to familiarize yourself with the steps required to introduce a Kubernetes cluster to your organization. Your choice of Kubernetes distribution is somewhat arbitrary, however you should consider the need to create them repeatedly to enable thorough testing. Head over to https://platform.jetstack.io/org/[ORG]/certinventory/cluster/[CLUSTER]/issuers . This is where you will locate any active Issuer objects in your registered cluster(s). From the TLS Protect For Kubernetes console, select ADD AN ISSUER to familiarize yourself with the steps required to introduce new Issuer objects (both native and external ) to your cluster. Start building! Use a public GitHub repository with Commit Signature Veficiation enabled. Use a CI/CD platform, such as Github Actions . Use Kubebuilder framework to increase your velocity and reduce the complexity inherent in developing any Kubernetes controller. Perform functional testing . Get certified ! Getting Help \u00b6 The cert-manager team have produced an article named Implementing External Issuers which is geared directly towards assisting developers like yourself. Pay special attention to the sections named Approval and Conditions . If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.","title":"Getting Started"},{"location":"Developers/Design-Patterns/Issuer/2-getting-started-issuer/#getting-started","text":"If you've made it here, you should already have a general understanding about Issuers and machine identities . Now you're ready to get started developing your Issuer solution.","title":"Getting Started"},{"location":"Developers/Design-Patterns/Issuer/2-getting-started-issuer/#steps","text":"Head over to TLS Protect For Kubernetes and select ACCESS YOUR ACCOUNT . Log In to your account or , if you don't already have one, select Sign Up , complete the Terms of Service and follow the on screen prompts. Note : new users will be allocated a organization name made of two randomly selected words (e.g. foxtrot-charlie) which is your private workspace within the SaaS platform. From the TLS Protect For Kubernetes console, select Clusters and CONNECT NEW CLUSTER to familiarize yourself with the steps required to introduce a Kubernetes cluster to your organization. Your choice of Kubernetes distribution is somewhat arbitrary, however you should consider the need to create them repeatedly to enable thorough testing. Head over to https://platform.jetstack.io/org/[ORG]/certinventory/cluster/[CLUSTER]/issuers . This is where you will locate any active Issuer objects in your registered cluster(s). From the TLS Protect For Kubernetes console, select ADD AN ISSUER to familiarize yourself with the steps required to introduce new Issuer objects (both native and external ) to your cluster. Start building! Use a public GitHub repository with Commit Signature Veficiation enabled. Use a CI/CD platform, such as Github Actions . Use Kubebuilder framework to increase your velocity and reduce the complexity inherent in developing any Kubernetes controller. Perform functional testing . Get certified !","title":"Steps"},{"location":"Developers/Design-Patterns/Issuer/2-getting-started-issuer/#getting-help","text":"The cert-manager team have produced an article named Implementing External Issuers which is geared directly towards assisting developers like yourself. Pay special attention to the sections named Approval and Conditions . If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.","title":"Getting Help"},{"location":"Developers/Design-Patterns/Issuer/3-functional-testing-issuer/","text":"Functional Testing \u00b6 During development of your Issuer solution, you should keep the following functional tests in mind for this design pattern. The test cases listed below are directly related to the requirements and considerations outlined for this use case. What is functional testing? To summarize Wikipedia : Functional testing is a QA process that sees a \"tester\" run through all documented functionality of a product or, in this case, an integrated solution. It's a great way to uncover bugs, unexpected behaviors and documentation errors. The functional tests documented below are provided as examples. Depending on the supported functionality of the target platform/service you're building for and/or the complexity of your solution, some tests listed below may not be necessary. Similarly, it's possible that you've got such a new or unique solution, that we haven't identified recommended functional tests yet. If you've got suggestions and/or functional tests that helped during your development, please let us know ! Reduce Confirmation Bias It can be extremely helpful, especially when writing documentation that accompanies your solution, to involve others on your team who haven't been involved in the development process. While you might be able to perform all functionality without even referencing the docs, it's possible that a fresh set of eyes will uncover typos or minor omissions that someone directly involved in development might miss. Basic Functionality Tests \u00b6 The following functionality tests should be applicable to every solution targeting this use case. Test Case Description Desired Outcome ISS-01 Documentation : Solution should be fully documented Both online and embedded CRD documentation (when applicable) is provided ISS-02 Error Handling : Perform an operation which you expect to fail (unsupported key size, missing/incomplete data, provider-centric policy violation, etc.) A meaningful error message will be recorded in the cert-manager logs and will propagate to the TLS Protect For Kubernetes front-end ISS-03 New Certificate : Provision a new certificate for use as a machine identity Certificate is delivered back to cert-manager and observably ready for use from within TLS Protect For Kubernetes ISS-04 Certificate Renewed : Renew certificate for use as a machine identity Certificate is delivered back to cert-manager and revised expiry date is visible from within TLS Protect For Kubernetes ISS-05 Approval Status : Without approval from the approver-policy component of TLS Protect For Kubernetes Enterprise, no certificate should be issued Unapproved certificates will be flagged as such in TLS Protect For Kubernetes ISS-06 Ingress Integration : Provide seamless integration with Ingress Controllers Ingresses enlisting the support of your Issuer solution will behave as per native Issuers with regard to machine identities Advanced Functionality Tests \u00b6 Depending on the exact functionality of the target solution, the following tests may or may not be applicable. Test Case Description Desired Outcome None","title":"Functional Testing"},{"location":"Developers/Design-Patterns/Issuer/3-functional-testing-issuer/#functional-testing","text":"During development of your Issuer solution, you should keep the following functional tests in mind for this design pattern. The test cases listed below are directly related to the requirements and considerations outlined for this use case. What is functional testing? To summarize Wikipedia : Functional testing is a QA process that sees a \"tester\" run through all documented functionality of a product or, in this case, an integrated solution. It's a great way to uncover bugs, unexpected behaviors and documentation errors. The functional tests documented below are provided as examples. Depending on the supported functionality of the target platform/service you're building for and/or the complexity of your solution, some tests listed below may not be necessary. Similarly, it's possible that you've got such a new or unique solution, that we haven't identified recommended functional tests yet. If you've got suggestions and/or functional tests that helped during your development, please let us know ! Reduce Confirmation Bias It can be extremely helpful, especially when writing documentation that accompanies your solution, to involve others on your team who haven't been involved in the development process. While you might be able to perform all functionality without even referencing the docs, it's possible that a fresh set of eyes will uncover typos or minor omissions that someone directly involved in development might miss.","title":"Functional Testing"},{"location":"Developers/Design-Patterns/Issuer/3-functional-testing-issuer/#basic-functionality-tests","text":"The following functionality tests should be applicable to every solution targeting this use case.","title":"Basic Functionality Tests"},{"location":"Developers/Design-Patterns/Issuer/3-functional-testing-issuer/#advanced-functionality-tests","text":"Depending on the exact functionality of the target solution, the following tests may or may not be applicable.","title":"Advanced Functionality Tests"},{"location":"Developers/Design-Patterns/Management-Layer/0-intro-management-layer/","text":"Management Layer \u00b6 This page has moved! Design patterns for TLS Protect have been moved to Venafi Dev Central. Please visit the Management Layer page on Dev Central for the latest information.","title":"Management Layer"},{"location":"Developers/Design-Patterns/Management-Layer/0-intro-management-layer/#management-layer","text":"This page has moved! Design patterns for TLS Protect have been moved to Venafi Dev Central. Please visit the Management Layer page on Dev Central for the latest information.","title":"Management Layer"},{"location":"Getting-Started/1-how-to-engage/","text":"Start Engaging with Venafi Ecosystem \u00b6 Venafi Ecosystem is the hub of innovation. It involves and relies on the participation of many different players including external Developers, customers, and Venafi internal stakeholders, all center around Machine Identity Management to safeguard world's machine identities. Venafi Ecosystem provides and maintains the infrastructure, tooling, support for the diverse set of players. Below are the different ways to engage with the Ecosystem depending on the role you play: Funded Developers Existing or Prospective Customers I want to build with Venafi","title":"How to Engage"},{"location":"Getting-Started/1-how-to-engage/#start-engaging-with-venafi-ecosystem","text":"Venafi Ecosystem is the hub of innovation. It involves and relies on the participation of many different players including external Developers, customers, and Venafi internal stakeholders, all center around Machine Identity Management to safeguard world's machine identities. Venafi Ecosystem provides and maintains the infrastructure, tooling, support for the diverse set of players. Below are the different ways to engage with the Ecosystem depending on the role you play: Funded Developers Existing or Prospective Customers I want to build with Venafi","title":"Start Engaging with Venafi Ecosystem"},{"location":"Getting-Started/customers/","text":"The most common use cases a Venafi customer has for Ecosystem can be captured in the flow graphs below. Use Case 1 : You need to know whether we already have an integration with a different technology. SDJS_Widget(\"A5C349CC4A4CF4C4017431177EDFA7B37D6\",87031,1,\"\"); Use Case 2 : You have a suggestion and a nice idea for an integration with a technology, please provide all the details necessary on Venafi ideas community channel. Don't forget to tag your account manager and solution architect. For any other issues, you can send us an issue report .","title":"For Existing or Prospective Customers"},{"location":"Getting-Started/funded-developers/","text":"Development Fund Program \u00b6 You can always review the details of the Development Fund Program . Milestones and Checkins \u00b6 A typical journey for a Developer funded by the program is organized by a series of milestones and actions. SDJS_Widget(\"9B655732E9F0B87CAE2F9687FDEDF6BCD81\",41500,1,\"\"); This journey is managed through our Ecosystem Management Platform. If you do not yet have access to the platform, send us a request . This process should be followed by most Developers who are funded through Venafi's Development Fund Program . In rare cases, exceptions have to be made. In which case, you will have milestones that are not part of the five outlined above. These milestone actions will be reflected in the above-mentioned platform. For any other issues, you can send us an issue report .","title":"For Funded Developers"},{"location":"Getting-Started/funded-developers/#development-fund-program","text":"You can always review the details of the Development Fund Program .","title":"Development Fund Program"},{"location":"Getting-Started/funded-developers/#milestones-and-checkins","text":"A typical journey for a Developer funded by the program is organized by a series of milestones and actions. SDJS_Widget(\"9B655732E9F0B87CAE2F9687FDEDF6BCD81\",41500,1,\"\"); This journey is managed through our Ecosystem Management Platform. If you do not yet have access to the platform, send us a request . This process should be followed by most Developers who are funded through Venafi's Development Fund Program . In rare cases, exceptions have to be made. In which case, you will have milestones that are not part of the five outlined above. These milestone actions will be reflected in the above-mentioned platform. For any other issues, you can send us an issue report .","title":"Milestones and Checkins"},{"location":"Getting-Started/general-inquiry/","text":"If you have a use case for an integration with Venafi: Send an us email or fill out the new use case form If you have a customer request to integration with Venafi: Send us an email or fill out the integration request form For any other inquires, you can send us a general inquiry .","title":"General Inquiry"},{"location":"Getting-Started/nav/","text":"How to Engage For Funded Developers For Existing or Prospective Customers Want to build with Venafi Development Fund Program General Inquiry","title":"Nav"},{"location":"Getting-Started/prospective-developers/","text":"Venafi Ecosystem is always welcoming new and past Developers to join and participate in building the future where all machine identities are protected. Developers get access to: Common design patterns and guides Kits with simulators for amazingly fast dev and test Pre-configured cloud instances for immediate, on-demand development Free and extensible trial for Venafi cloud Full support from Venafi engineers Go-to-market leadership ready to educate and drive demand To become a Developer of Venafi Ecosystem, please check out the following pages for details: Development Fund Program \u00b6 General Inquiry \u00b6 For any other issues, you can send us an issue report .","title":"Want to build with Venafi"},{"location":"Manifesto/nav/","text":"Core Statement Operating Principles","title":"Nav"},{"location":"Manifesto/operating-principles/","text":"Venafi Ecosystem decision making is guided by 8 core principles: Ecosystem always futureproofs customer success \u2013 for the organization, team, champion, and their career \u2013 by bringing together the world\u2019s leaders and innovators to solve 100% of Machine Identity Management problems required today and into the future. The Ecosystem predicts the future needs of Customers ahead of their needs; with Customers continuing to use more of Venafi to solve Machine Identity Management problems and increase their success with Ecosystem-developed solutions. Ecosystem values every developer and is building for developer success . Developers have every opportunity to complete projects, promote to Customers, drive use by Customers, increase contribution, and grow licensed revenue. Ecosystem enables Developers to build more innovation faster without wasting time. Developers value this and see the benefit in time to get their innovation to Customers, write less code, update faster, and see use grow faster. Ecosystem always innovates, never copies to futureproof customer success . Ecosystem initiatives are unique to Venafi and never copies of a competitor. This means the Ecosystem is always bringing new developer solutions for Machine Identity Management ahead of competition. It is always looking for new ideas from innovators not past success. Speed matters . Many decisions are reversible and do not need extensive study. Ecosystem encourages and values calculated risk taking. Ecosystem values failures as opportunities to learn from. Ecosystem is never afraid to fail and learn more to improve. Because the Ecosystem is working to the future, it accepts that it may be misunderstood for long periods of time. Ecosystem is always improving the developer experience so that almost all developer project started are completed and that every year the time to complete projects decreases by 50%. Wherever possible, developer experience is focused on a more gamified and interactive approach, rather than a checkbox exercise. Ecosystem builds intelligence by collecting developer and customer usage data so that 100% of customer use of Marketplace and 100% use by Customers of developer solutions can be learned from and used to provide new insights and improvements that futureproofs customer success. Ecosystem makes sure 100% of Developers are never left behind to futureproof customer success when updates to Venafi APIs are made by providing training, documentation, tools that make any transition and updates easy and fast. Ecosystem certifies 100% of new developer solutions that meet published Venafi standards to futureproof customer success and 100% of existing developer solutions are recertified at least once per year.","title":"Operating Principles"},{"location":"Manifesto/statements/","text":"The Venafi Ecosystem (\"Ecosystem\") is the innovation engine that futureproofs Customer success. Ecosystem innovation is the identification and development of new design patterns, solving problems in new ways, and building new business models - all of which makes it easier, faster, consistent, and reliable for Customers to use Machine Identity Management. The Ecosystem prioritizes outcomes for the Design Customer of the Future. Venafi is the organizer and a participant in the Ecosystem where the majority of solutions are built by external Developers and Customers. Developers are startups, consultancies, leading technologies, and individuals that create solutions that perform or make use of Machine Identity Management. Innovation occurs naturally with the most diverse range of Developers building solutions that benefit Venafi Customers. The outcome is that Customers have the confidence to deliver their Machine Identity Management strategy today and into the future. A clear measure of Customer confidence is consistent, increasing use of Ecosystem-developed solutions. This drives a secondary measure: more Developers build more solutions for Venafi Customers, increasing the diversity in terms of Developers and offerings. Each year at least 20 Developers come to Venafi to join the Ecosystem and build for Venafi. All of this makes it easier and faster for Venafi to recruit new Developers to the Ecosystem. And thirdly: more Developers are educating on the need and correct design pattern for Machine Identity Management.","title":"Core Statement"},{"location":"Programs/devfund/","text":"Technology is advancing faster than ever before, software development is going faster, innovation is driven to go with a faster speed. To help with fastsecure with machine identity management, Venafi established a $12.5 million Development Fund to bring to life new integrated solutions for DevOps, cloud native, microservices, IoT and beyond. Under the management of Venafi Ecosystem, we seek for innovation that identifies and develops new design patterns, finds new ways of solving problems, and builds new business models. Submit your idea by filling out this DevFund Application Developers \u00b6 In addition to traditional parnter Developers , we extend our offer to the following types of Developers. Venafi IndieDevs \u00b6 Individual developers make a unique contribution to the open-source community and will provide Venafi customers with cutting edge solutions in the machine identity management space. An indieDev can belong to an organization with the exception of Venafi competitors, but the contract is between Venafi and the individual. Venafi UniversityDevs \u00b6 Venafi is expanding the network of innovation to top universities in the world. Oxford University and Carnegie Mellon University are now investigating machine identity management innovations and creating new open-source solutions. Process \u00b6 SDJS_Widget(\"BED58066764839EECE7278C0D8B6645F61F\",69931,1,\"\"); Principles \u00b6 Venafi does not dictate the speed of your progress We do not impose on any timeline for the completion of each milestone or the project We care about the results, the outcome, not your day-to-day process Developer takes the initiative informing Ecosystem team when you are ready to deliver and we will set up meetings to evaluate We approve the deliverables for each milestone when they meet production quality that is normally expected for an enterprise solution We provide feedback per request Developer owns the intellectural property rights We invoice if the deliverables meet the above stated standard AND the Venafi team explicitly approves the quality of the deliverables, per the SOE agreement Innovative solutions \u00b6 Venafi Ecosystem has successfully sponsored a diverse group of Developers who built innovations that are listed on Venafi Marketplace .","title":"Development Fund Program"},{"location":"Programs/devfund/#developers","text":"In addition to traditional parnter Developers , we extend our offer to the following types of Developers.","title":"Developers"},{"location":"Programs/devfund/#process","text":"SDJS_Widget(\"BED58066764839EECE7278C0D8B6645F61F\",69931,1,\"\");","title":"Process"},{"location":"Programs/devfund/#principles","text":"Venafi does not dictate the speed of your progress We do not impose on any timeline for the completion of each milestone or the project We care about the results, the outcome, not your day-to-day process Developer takes the initiative informing Ecosystem team when you are ready to deliver and we will set up meetings to evaluate We approve the deliverables for each milestone when they meet production quality that is normally expected for an enterprise solution We provide feedback per request Developer owns the intellectural property rights We invoice if the deliverables meet the above stated standard AND the Venafi team explicitly approves the quality of the deliverables, per the SOE agreement","title":"Principles"},{"location":"Programs/devfund/#innovative-solutions","text":"Venafi Ecosystem has successfully sponsored a diverse group of Developers who built innovations that are listed on Venafi Marketplace .","title":"Innovative solutions"},{"location":"Testing-Ground/testing-diagrams/","text":"Testing Diagrams \u00b6 Here's an example of a diagram: %%{ init: { \"sequence\": { \"showSequenceNumbers\": true, \"messageAlign\": \"center\" } } }%% sequenceDiagram actor EU as User participant IP as Integrated Platform participant V as Venafi activate EU EU->IP: Enter required SERVICE ACCOUNT connection information (Venafi URL/ClientID/Username/Password) deactivate EU activate IP IP->IP: Store required connection information SECURELY activate V IP->V: Use connection information to call '/vedauth/authorize' providing UN, PW, ClientID, & Scope V-->IP: Returns Access/Refresh tokens and expiry information IP->IP: Store tokens & expiry info IP->V: Use 'access_token' to authorize API calls to Venafi alt [access_token is still valid] V-->IP: API call returns data successfully else [access_token is expired] V-->IP: Returns 'access_token is expired' IP->V: Calls '/vedauth/authorize/' providing ClientID & refresh_token V-->IP: Returns fresh Access/Refresh tokens & expiry info IP->IP: Update stored tokens & expiry info with new values IP->V: Use 'access_token' to authorize API calls to Venafi V-->IP: API call returns data successfully end IP->V: Call 'vedauth/Revoke/token' to clean up active grant deactivate IP deactivate V","title":"Testing Diagrams"},{"location":"Testing-Ground/testing-diagrams/#testing-diagrams","text":"Here's an example of a diagram: %%{ init: { \"sequence\": { \"showSequenceNumbers\": true, \"messageAlign\": \"center\" } } }%% sequenceDiagram actor EU as User participant IP as Integrated Platform participant V as Venafi activate EU EU->IP: Enter required SERVICE ACCOUNT connection information (Venafi URL/ClientID/Username/Password) deactivate EU activate IP IP->IP: Store required connection information SECURELY activate V IP->V: Use connection information to call '/vedauth/authorize' providing UN, PW, ClientID, & Scope V-->IP: Returns Access/Refresh tokens and expiry information IP->IP: Store tokens & expiry info IP->V: Use 'access_token' to authorize API calls to Venafi alt [access_token is still valid] V-->IP: API call returns data successfully else [access_token is expired] V-->IP: Returns 'access_token is expired' IP->V: Calls '/vedauth/authorize/' providing ClientID & refresh_token V-->IP: Returns fresh Access/Refresh tokens & expiry info IP->IP: Update stored tokens & expiry info with new values IP->V: Use 'access_token' to authorize API calls to Venafi V-->IP: API call returns data successfully end IP->V: Call 'vedauth/Revoke/token' to clean up active grant deactivate IP deactivate V","title":"Testing Diagrams"},{"location":"Testing-Ground/testing-fullpage-embeds/","text":"Embedding Things \u00b6 (function() { var script = document.createElement('script'); script.src = \"https://paperform.co/__embed.min.js\";document.body.appendChild(script); })()","title":"Embedding Things"},{"location":"Testing-Ground/testing-fullpage-embeds/#embedding-things","text":"(function() { var script = document.createElement('script'); script.src = \"https://paperform.co/__embed.min.js\";document.body.appendChild(script); })()","title":"Embedding Things"},{"location":"Testing-Ground/testing-inline-embeds/","text":"Embedding Things \u00b6 (function() {var script = document.createElement('script'); script.src = \"https://paperform.co/__embed.min.js\"; document.body.appendChild(script); })()","title":"Embedding Things"},{"location":"Testing-Ground/testing-inline-embeds/#embedding-things","text":"(function() {var script = document.createElement('script'); script.src = \"https://paperform.co/__embed.min.js\"; document.body.appendChild(script); })()","title":"Embedding Things"},{"location":"Tools/nav/","text":"For Developers VCert APIs Adaptable Framework HSM Validation Utility","title":"Nav"},{"location":"Tools/API/overview-api/","text":"Venafi REST APIs \u00b6 The Venafi TLS Protect Cloud and TLS Protect Datacenter REST APIs enable developers to seamlessly integrate machine identity management into other products, platforms and services. Building your solution using Venafi APIs provides an excellent experience for the end user because they don't need to download or install any additional bits - typically they just have to follow a simple configuration process to establish connection between Venafi and the target application, service or platform. Once complete, users are able to perform all necessary functions involving machine identities directly from the interfaces and platforms they're already using every day. Official API Documentation \u00b6 TLS Protect Cloud TLS Protect Datacenter","title":"APIs"},{"location":"Tools/API/overview-api/#venafi-rest-apis","text":"The Venafi TLS Protect Cloud and TLS Protect Datacenter REST APIs enable developers to seamlessly integrate machine identity management into other products, platforms and services. Building your solution using Venafi APIs provides an excellent experience for the end user because they don't need to download or install any additional bits - typically they just have to follow a simple configuration process to establish connection between Venafi and the target application, service or platform. Once complete, users are able to perform all necessary functions involving machine identities directly from the interfaces and platforms they're already using every day.","title":"Venafi REST APIs"},{"location":"Tools/API/overview-api/#official-api-documentation","text":"TLS Protect Cloud TLS Protect Datacenter","title":"Official API Documentation"},{"location":"Tools/API/Cloud/0-intro-cloud-api/","text":"General Tips \u00b6 Ideally, certificates should be referenced using the GUID of the certificate object Listing all certificates in a folder could be problematic because there may be a very high number of certificates in some policy folders. A better approach would be to check (search) whether a specific certificate already exists within a given policy folder.","title":"0 intro cloud api"},{"location":"Tools/API/Cloud/0-intro-cloud-api/#general-tips","text":"Ideally, certificates should be referenced using the GUID of the certificate object Listing all certificates in a folder could be problematic because there may be a very high number of certificates in some policy folders. A better approach would be to check (search) whether a specific certificate already exists within a given policy folder.","title":"General Tips"},{"location":"Tools/API/Datacenter/0-intro-datacenter-api/","text":"","title":"0 intro datacenter api"},{"location":"Tools/Adaptable-Framework/0-intro-adaptable-framework/","text":"Adaptable Framework \u00b6 Venafi Adaptable Drivers provide a quick, easy framework to build solutions, primarily with target application platforms (web servers, network devices, application firewalls, etc.) and CAs (certificate authorities), but also to support flexible workflow and logging needs for unique environments or use cases. It will likely become clear over the next few pages which specific Adaptable Framework type is applicable to your use case. Use the power of the Ecosystem! If you still aren't sure which Adaptable Driver type best supports your target use case after reading through the next few pages, describe your use case to the Venafi Warrior Community to see what is recommended! Each of Venafi's Adaptable Drivers provides a common set of variables required by the majority of applicable use cases that are supported by TLS Protect Datacenter natively, including things like the hostname/IP of the target application device or cloud service, as well as the necessary credentials to make the connection to the target. This data can be referenced/retrieved from Venafi by using hash tables included in each function in the Adaptable Driver - more on this later. Some Adaptable Drivers also let you define additional text fields, yes/no (boolean) fields, and an additional password credential field, which you can then use to elicit different behaviors or to pass additional data to the system or service to which you are building a solution. Each type of Adaptable Driver will have slightly different options for customization. These will be described in more detail in the complete documentation after you've selected which type of Adaptable Driver you will be writing. Adaptable drivers depend on a Microsoft PowerShell script hosted on each Venafi server to execute functions corresponding to standard certificate lifecycle stages or TLS Protect Datacenter events. Note To work effectively with any Venafi Adaptable solution, you must have some working knowledge of PowerShell scripting, or you must have equivalent experience with a scripting language similar to PowerShell.","title":"Adaptable Framework"},{"location":"Tools/Adaptable-Framework/0-intro-adaptable-framework/#adaptable-framework","text":"Venafi Adaptable Drivers provide a quick, easy framework to build solutions, primarily with target application platforms (web servers, network devices, application firewalls, etc.) and CAs (certificate authorities), but also to support flexible workflow and logging needs for unique environments or use cases. It will likely become clear over the next few pages which specific Adaptable Framework type is applicable to your use case. Use the power of the Ecosystem! If you still aren't sure which Adaptable Driver type best supports your target use case after reading through the next few pages, describe your use case to the Venafi Warrior Community to see what is recommended! Each of Venafi's Adaptable Drivers provides a common set of variables required by the majority of applicable use cases that are supported by TLS Protect Datacenter natively, including things like the hostname/IP of the target application device or cloud service, as well as the necessary credentials to make the connection to the target. This data can be referenced/retrieved from Venafi by using hash tables included in each function in the Adaptable Driver - more on this later. Some Adaptable Drivers also let you define additional text fields, yes/no (boolean) fields, and an additional password credential field, which you can then use to elicit different behaviors or to pass additional data to the system or service to which you are building a solution. Each type of Adaptable Driver will have slightly different options for customization. These will be described in more detail in the complete documentation after you've selected which type of Adaptable Driver you will be writing. Adaptable drivers depend on a Microsoft PowerShell script hosted on each Venafi server to execute functions corresponding to standard certificate lifecycle stages or TLS Protect Datacenter events. Note To work effectively with any Venafi Adaptable solution, you must have some working knowledge of PowerShell scripting, or you must have equivalent experience with a scripting language similar to PowerShell.","title":"Adaptable Framework"},{"location":"Tools/Adaptable-Framework/1-prereqs-adaptable-framework/","text":"Prerequisites \u00b6 Before you begin writing an Adaptable Driver, there are a few important things to consider. Note Venafi Adaptable Drivers support Venafi TLS Protect Datacenter only. Venafi Product Management is working on a similar framework for TLS Protect Cloud use cases. Please sign up here to be notified when developer tools are available for TLS Protect Cloud . Environment Dependencies \u00b6 Since the Adaptable Framework is based on PowerShell, you'll need a Windows machine with the following: Windows PowerShell 5.1 Warning PowerShell 7 is not yet supported by TLS Protect Datacenter .NET 4.7.2 or later TLS 1.3 If your product does not support TLS 1.3, you will need to add the following code to your Adaptable script in order for it to work with the Venafi Platform. [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls -bor [Net.SecurityProtocolType]::Tls11 -bor [Net.SecurityProtocolType]::Tls12 Other Considerations \u00b6 In most cases, any information required by both Venafi and the target integrated solution can be passed to and from Venafi through the Adaptable Driver script and the existing functions contained therein. That said, there are certain scenarios which require interacting directly with the API. Calling Venafi APIs from Adaptable Drivers \u00b6 If your Adaptable Driver requires access to the Venafi API, you'll need to do the following: Create an API Application Integration that's specific to your script. This is a required step in which you register your application with Trust Protection Platform. For more information, see Integrating other systems with Venafi products . Best Practice When creating your API Application Integration for use with OAuth, consider the following best practice settings. Under Access Limits in the Create Application Integration panel, select these options: Set Grant and token expiration to Configure Set Grant Expiration Period to 1 day Set Token Refresh to Disabled If you don't already have one, create a Username credential that has been associated with a service account that has permissions to the API application. See Creating user name or password credentials . Unique use cases like this one should be rare, but occasionally do present themselves and require additional consideration. Use the power of the Ecosystem! In the event you need functionality that isn't supported by the Adaptable Driver framework natively, please check the Venafi Warrior Community to see if your question might have already been asked by previous developers, and if there's an accepted workaround. If not, post a new question!","title":"Prerequisites"},{"location":"Tools/Adaptable-Framework/1-prereqs-adaptable-framework/#prerequisites","text":"Before you begin writing an Adaptable Driver, there are a few important things to consider. Note Venafi Adaptable Drivers support Venafi TLS Protect Datacenter only. Venafi Product Management is working on a similar framework for TLS Protect Cloud use cases. Please sign up here to be notified when developer tools are available for TLS Protect Cloud .","title":"Prerequisites"},{"location":"Tools/Adaptable-Framework/1-prereqs-adaptable-framework/#environment-dependencies","text":"Since the Adaptable Framework is based on PowerShell, you'll need a Windows machine with the following: Windows PowerShell 5.1 Warning PowerShell 7 is not yet supported by TLS Protect Datacenter .NET 4.7.2 or later TLS 1.3 If your product does not support TLS 1.3, you will need to add the following code to your Adaptable script in order for it to work with the Venafi Platform. [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls -bor [Net.SecurityProtocolType]::Tls11 -bor [Net.SecurityProtocolType]::Tls12","title":"Environment Dependencies"},{"location":"Tools/Adaptable-Framework/1-prereqs-adaptable-framework/#other-considerations","text":"In most cases, any information required by both Venafi and the target integrated solution can be passed to and from Venafi through the Adaptable Driver script and the existing functions contained therein. That said, there are certain scenarios which require interacting directly with the API.","title":"Other Considerations"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/","text":"Overview \u00b6 Consider the following guidelines and expected behaviors, which apply generally to all types of Adaptable Framework drivers (CA, Application, Log, Workflow, etc.). Drivers rely on System.Management.Automation in .NET to invoke PowerShell functions inside a locally hosted script PowerShell functions are responsible for ensuring that data meets the requirements of the integration point All functions (except where noted) must be present in the script, but they are optional from a logic standpoint. Hash Tables \u00b6 Venafi passes variables to (and receives them from) PowerShell functions in the form of hash tables, which are generally easier to work with and allow for the addition of variables without changing the function definition. A general hash table, $General , which includes a common set of data available from Venafi, is passed to all the functions A specific hash table, $Specific , which includes data that is applicable only to the specific function, is passed to some functions that require additional data All functions must return a single hash table that includes a result along with any other variables that the function is required to return - check the documentation for the function in question to see what is expected in the return Naming Conventions \u00b6 To avoid collisions, you should adopt a standard naming convention that will be used when creating objects (certificates, devices, applications) in Venafi. Collisions can occur when the name you define already exists in Venafi's inventory. One option to avoid collisions is to use the same prefix or suffix, and then add something unique to the name. Suppose your driver connects to a device object via API and imports all the machine identities currently in use on the device. In addition to the certificates themselves being imported, a unique application object must be created as well, which will contain all the metadata (port, partition, profile, configuration options, etc.) needed for Venafi to automatically provision that certificate during a renewal. Note When creating new PowerShell scripts for use with adaptable drivers, keep in mind that the file name is used to identify your script from within the associated object (and within the policy for the Adaptable Application driver) in Trust Protection Platform. Using logical names can help you and other administrators recognize the purpose and intent of each script. Credentials & Authentication \u00b6 Credential objects store the credentials Trust Protection Platform uses to authenticate with devices, applications, CAs, and other systems in a user's infrastructure. The stored credential may be a password, a username and password, a certificate, a file paired with a password, or a private key. Trust Protection Platform requires these credentials so it can manage the certificates associated with these devices, applications, and CAs. Credential objects provide an innovative way to centrally manage and share your system credentials. Each credential object can be associated with a single device or application, or it can be shared by multiple objects. After you create your system\u2019s credential objects, you do not have to repeat the credential configuration for each device or application. You simply reference the existing credential object. If the credential changes\u2014for example, an organization might change username and password credentials every 90 days\u2014you merely update the single credential object to give Trust Protection Platform access to all associated devices and applications. Reuse credential objects wherever standardization is possible to avoid creating extraneous objects. Recommend assigning credentials to a Policy folder that contains multiple devices. The policy credentials allow multiple devices to use the same credential. Certificate \"Installations\" \u00b6 Within a customer\u2019s environment, there may be circumstances that require the same certificate to be installed in multiple locations (high-availability, load balancing, traffic inspection, etc.). If that is the case, the Venafi platform must be made aware of each location. This ensures there are no blind spots for the Security or PKI team, and also provides Venafi the information necessary to automatically provision and activate that certificate during future renewal operations. Possible Outage! If your application supports multiple installations of the same certificate, it is critical that ALL those locations are reported back to Venafi. Data Validation \u00b6 You should implement effective data validation in order to catch errors in the script: Check values for validity that are being passed into functions Check values for validity before passing data back to Venafi Logging \u00b6 Generally, Adaptable Framework scripts don\u2019t need to do any logging unless it\u2019s for temporary, debugging purposes. The Adaptable drivers are logging to the standard Venafi logging channel when they call various PowerShell functions. Beginning in v19.3, developers can toggle debug logging for individual Adaptable drivers. This sets a $DEBUG_FILE global variable in the Adaptable driver. If toggled on, the script should be logging \u2013 If toggled off, it shouldn\u2019t. The $DEBUG_FILE variable gets set automatically to a suggested file path on the Venafi server for the script to write logs to, using a unique identifier. This is to avoid issues if there are multiple instances trying to write data to the same file. The resulting log file appears in the \\Logs directory by default. (e.g. C:\\Program Files\\Venafi\\Logs ) Permanent Logs If additional, permanent logs are needed, use Write-EventLog to capture important logging and debug information to the Windows Event Log Error Handling \u00b6 PowerShell functions must not return errors; rather, they must throw exceptions in the same way that actual PowerShell errors do. Adaptable drivers treat exceptions thrown by a PowerShell function as a fatal error and then halt processing. Thrown exceptions are handled as unexpected. If there is an error, we recommended you use Result=\"Failure\" and pass the error description in the Error=\"\" parameter. Please write effective error messages that tell users what went wrong and how to fix the issue.","title":"Overview"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#overview","text":"Consider the following guidelines and expected behaviors, which apply generally to all types of Adaptable Framework drivers (CA, Application, Log, Workflow, etc.). Drivers rely on System.Management.Automation in .NET to invoke PowerShell functions inside a locally hosted script PowerShell functions are responsible for ensuring that data meets the requirements of the integration point All functions (except where noted) must be present in the script, but they are optional from a logic standpoint.","title":"Overview"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#hash-tables","text":"Venafi passes variables to (and receives them from) PowerShell functions in the form of hash tables, which are generally easier to work with and allow for the addition of variables without changing the function definition. A general hash table, $General , which includes a common set of data available from Venafi, is passed to all the functions A specific hash table, $Specific , which includes data that is applicable only to the specific function, is passed to some functions that require additional data All functions must return a single hash table that includes a result along with any other variables that the function is required to return - check the documentation for the function in question to see what is expected in the return","title":"Hash Tables"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#naming-conventions","text":"To avoid collisions, you should adopt a standard naming convention that will be used when creating objects (certificates, devices, applications) in Venafi. Collisions can occur when the name you define already exists in Venafi's inventory. One option to avoid collisions is to use the same prefix or suffix, and then add something unique to the name. Suppose your driver connects to a device object via API and imports all the machine identities currently in use on the device. In addition to the certificates themselves being imported, a unique application object must be created as well, which will contain all the metadata (port, partition, profile, configuration options, etc.) needed for Venafi to automatically provision that certificate during a renewal. Note When creating new PowerShell scripts for use with adaptable drivers, keep in mind that the file name is used to identify your script from within the associated object (and within the policy for the Adaptable Application driver) in Trust Protection Platform. Using logical names can help you and other administrators recognize the purpose and intent of each script.","title":"Naming Conventions"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#credentials-authentication","text":"Credential objects store the credentials Trust Protection Platform uses to authenticate with devices, applications, CAs, and other systems in a user's infrastructure. The stored credential may be a password, a username and password, a certificate, a file paired with a password, or a private key. Trust Protection Platform requires these credentials so it can manage the certificates associated with these devices, applications, and CAs. Credential objects provide an innovative way to centrally manage and share your system credentials. Each credential object can be associated with a single device or application, or it can be shared by multiple objects. After you create your system\u2019s credential objects, you do not have to repeat the credential configuration for each device or application. You simply reference the existing credential object. If the credential changes\u2014for example, an organization might change username and password credentials every 90 days\u2014you merely update the single credential object to give Trust Protection Platform access to all associated devices and applications. Reuse credential objects wherever standardization is possible to avoid creating extraneous objects. Recommend assigning credentials to a Policy folder that contains multiple devices. The policy credentials allow multiple devices to use the same credential.","title":"Credentials & Authentication"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#certificate-installations","text":"Within a customer\u2019s environment, there may be circumstances that require the same certificate to be installed in multiple locations (high-availability, load balancing, traffic inspection, etc.). If that is the case, the Venafi platform must be made aware of each location. This ensures there are no blind spots for the Security or PKI team, and also provides Venafi the information necessary to automatically provision and activate that certificate during future renewal operations. Possible Outage! If your application supports multiple installations of the same certificate, it is critical that ALL those locations are reported back to Venafi.","title":"Certificate \"Installations\""},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#data-validation","text":"You should implement effective data validation in order to catch errors in the script: Check values for validity that are being passed into functions Check values for validity before passing data back to Venafi","title":"Data Validation"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#logging","text":"Generally, Adaptable Framework scripts don\u2019t need to do any logging unless it\u2019s for temporary, debugging purposes. The Adaptable drivers are logging to the standard Venafi logging channel when they call various PowerShell functions. Beginning in v19.3, developers can toggle debug logging for individual Adaptable drivers. This sets a $DEBUG_FILE global variable in the Adaptable driver. If toggled on, the script should be logging \u2013 If toggled off, it shouldn\u2019t. The $DEBUG_FILE variable gets set automatically to a suggested file path on the Venafi server for the script to write logs to, using a unique identifier. This is to avoid issues if there are multiple instances trying to write data to the same file. The resulting log file appears in the \\Logs directory by default. (e.g. C:\\Program Files\\Venafi\\Logs ) Permanent Logs If additional, permanent logs are needed, use Write-EventLog to capture important logging and debug information to the Windows Event Log","title":"Logging"},{"location":"Tools/Adaptable-Framework/2-overview-adaptable-framework/#error-handling","text":"PowerShell functions must not return errors; rather, they must throw exceptions in the same way that actual PowerShell errors do. Adaptable drivers treat exceptions thrown by a PowerShell function as a fatal error and then halt processing. Thrown exceptions are handled as unexpected. If there is an error, we recommended you use Result=\"Failure\" and pass the error description in the Error=\"\" parameter. Please write effective error messages that tell users what went wrong and how to fix the issue.","title":"Error Handling"},{"location":"Tools/Adaptable-Framework/3-writing-adaptable-drivers/","text":"Writing Adaptable Drivers \u00b6 Venafi Adaptable Drivers provide a way quick, easy framework to build solutions, primarily with target application platforms (web servers, network devices, application firewalls, etc.) and CAs (certificate authorities), but also to support flexible workflow and logging needs for unique environments. Note Venafi Adaptable Drivers support Venafi TLS Protect Datacenter only. Venafi Product Management is working on a similar framework for TLS Protect Cloud use cases. Please sign up here to be notified when developer tools are available for TLS Protect Cloud . Getting Started \u00b6 Read through this section on the Adaptable Framework (You're almost done!) Decide which DevKit you'll need below Build & test your driver using the tools provided in the DevKit Test your driver against TLS Protect Datacenter Submit your driver to Cool Solutions (Venafi's managed GitLab instance) Note You will need a Venafi user account in order to access.. Complete the Marketplace Listing Questionnaire Adaptable Driver Types \u00b6 Adaptable CA Adaptable App Adaptable Log Adaptable Workflow Adaptable Bulk Provisioning Choose this if you are building a solution between Venafi and a Machine Identity Producer , like a Certificate Authority or Managed PKI. Adaptable CA Full Documentation Choose this if you are building a solution between Venafi and a Machine Identity Consumer , like an application server, network device, WAF , etc. Adaptable Application Full Documentation Choose this if you are building a solution that will be used to perform virtually any programmatic task in response to the logging of a Venafi event. Adaptable Log Full Documentation Choose this if you are building a solution with the goal of further customizing Venafi's native approval workflows. Adaptable Workflow Full Documentation This use case is similar to the \"Adaptable App.\" The main difference is \"Bulk Provisioning\" was designed to provision many machine identities to a target using as few API calls as possible. Choose this if you are building a solution between Venafi and a Machine Identity Consumer , like a NGFW, traffic inspection device, or something else that needs many certificates with few connections to the target device. Adaptable Bulk Provisioning Full Documentation","title":"Writing Adaptable Drivers"},{"location":"Tools/Adaptable-Framework/3-writing-adaptable-drivers/#writing-adaptable-drivers","text":"Venafi Adaptable Drivers provide a way quick, easy framework to build solutions, primarily with target application platforms (web servers, network devices, application firewalls, etc.) and CAs (certificate authorities), but also to support flexible workflow and logging needs for unique environments. Note Venafi Adaptable Drivers support Venafi TLS Protect Datacenter only. Venafi Product Management is working on a similar framework for TLS Protect Cloud use cases. Please sign up here to be notified when developer tools are available for TLS Protect Cloud .","title":"Writing Adaptable Drivers"},{"location":"Tools/Adaptable-Framework/3-writing-adaptable-drivers/#getting-started","text":"Read through this section on the Adaptable Framework (You're almost done!) Decide which DevKit you'll need below Build & test your driver using the tools provided in the DevKit Test your driver against TLS Protect Datacenter Submit your driver to Cool Solutions (Venafi's managed GitLab instance) Note You will need a Venafi user account in order to access.. Complete the Marketplace Listing Questionnaire","title":"Getting Started"},{"location":"Tools/Adaptable-Framework/3-writing-adaptable-drivers/#adaptable-driver-types","text":"Adaptable CA Adaptable App Adaptable Log Adaptable Workflow Adaptable Bulk Provisioning Choose this if you are building a solution between Venafi and a Machine Identity Producer , like a Certificate Authority or Managed PKI. Adaptable CA Full Documentation Choose this if you are building a solution between Venafi and a Machine Identity Consumer , like an application server, network device, WAF , etc. Adaptable Application Full Documentation Choose this if you are building a solution that will be used to perform virtually any programmatic task in response to the logging of a Venafi event. Adaptable Log Full Documentation Choose this if you are building a solution with the goal of further customizing Venafi's native approval workflows. Adaptable Workflow Full Documentation This use case is similar to the \"Adaptable App.\" The main difference is \"Bulk Provisioning\" was designed to provision many machine identities to a target using as few API calls as possible. Choose this if you are building a solution between Venafi and a Machine Identity Consumer , like a NGFW, traffic inspection device, or something else that needs many certificates with few connections to the target device. Adaptable Bulk Provisioning Full Documentation","title":"Adaptable Driver Types"},{"location":"Tools/Adaptable-Framework/4-submitting-your-adaptable-driver/","text":"Submitting/Updating \u00b6 You've written an amazing Adaptable Driver and are now ready to make it available for users of the Machine Identity Management Control Plane . Or maybe you're ready to publish some bug fixes or feature enhancements to an existing solution. Either way, that's awesome! As a Venafi partner, you'll have a dedicated group in our GitLab instance where you can manage your own repository . New Solution \u00b6 If this is a new solution, please reach out to the Venafi Ecosystem team. Existing Solution \u00b6 If this is an update to an existing solution, please submit a Merge Request to your target repository and the update will be reviewed by the proper parties before being automatically updated on the Venafi Marketplace .","title":"Submitting/Updating"},{"location":"Tools/Adaptable-Framework/4-submitting-your-adaptable-driver/#submittingupdating","text":"You've written an amazing Adaptable Driver and are now ready to make it available for users of the Machine Identity Management Control Plane . Or maybe you're ready to publish some bug fixes or feature enhancements to an existing solution. Either way, that's awesome! As a Venafi partner, you'll have a dedicated group in our GitLab instance where you can manage your own repository .","title":"Submitting/Updating"},{"location":"Tools/Adaptable-Framework/4-submitting-your-adaptable-driver/#new-solution","text":"If this is a new solution, please reach out to the Venafi Ecosystem team.","title":"New Solution"},{"location":"Tools/Adaptable-Framework/4-submitting-your-adaptable-driver/#existing-solution","text":"If this is an update to an existing solution, please submit a Merge Request to your target repository and the update will be reviewed by the proper parties before being automatically updated on the Venafi Marketplace .","title":"Existing Solution"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/","text":"Managing Your Repo \u00b6 Venafi provides access to our managed GitLab instance to streamline code and script submissions for ecosystem solutions. GitLab provides better visibility and version control and more consistent documentation. Automations \u00b6 A number of default automations are enabled by default to enhance the user experience for both you as a developer, as well as end users of the solution. Please feel free to adapt to fit your needs. Default GitLab Pipeline \u00b6 Name Description Run Stage prepare_description.yml Reads a version.txt file in the root of the repo and stores it as $version in description.env for future use in the pipeline prepare build_pdf.yml Generates a PDF file from the README.md build release.yml Creates a release using the $version from the prepare stage and publishes the PDF version of the README release Documentation \u00b6 All repositories should include a README file with any information needed to configure the integration. An example repository with sample documentation is available here . Feel free to copy and use as a starting point. Account Required Some of the resources on this page will require a Venafi user account in order to access. Please feel free to create one. If you encounter any issues, please let us know . Docs Required All new projects and merge requests will be required to have accompanying documentation. Merge Requests \u00b6 The main branch is protected in all Ecosystem repositories. All changes must be committed to a separate branch and a merge request must be opened. Venafi teams will automatically be notified and will begin code review. We try to respond as quickly as possible. Code Review \u00b6 Venafi teams will review the committed code and merge to the main branch after passing review.","title":"Managing Your Repo"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/#managing-your-repo","text":"Venafi provides access to our managed GitLab instance to streamline code and script submissions for ecosystem solutions. GitLab provides better visibility and version control and more consistent documentation.","title":"Managing Your Repo"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/#automations","text":"A number of default automations are enabled by default to enhance the user experience for both you as a developer, as well as end users of the solution. Please feel free to adapt to fit your needs.","title":"Automations"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/#default-gitlab-pipeline","text":"Name Description Run Stage prepare_description.yml Reads a version.txt file in the root of the repo and stores it as $version in description.env for future use in the pipeline prepare build_pdf.yml Generates a PDF file from the README.md build release.yml Creates a release using the $version from the prepare stage and publishes the PDF version of the README release","title":"Default GitLab Pipeline"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/#documentation","text":"All repositories should include a README file with any information needed to configure the integration. An example repository with sample documentation is available here . Feel free to copy and use as a starting point. Account Required Some of the resources on this page will require a Venafi user account in order to access. Please feel free to create one. If you encounter any issues, please let us know . Docs Required All new projects and merge requests will be required to have accompanying documentation.","title":"Documentation"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/#merge-requests","text":"The main branch is protected in all Ecosystem repositories. All changes must be committed to a separate branch and a merge request must be opened. Venafi teams will automatically be notified and will begin code review. We try to respond as quickly as possible.","title":"Merge Requests"},{"location":"Tools/Adaptable-Framework/5-managing-your-repo/#code-review","text":"Venafi teams will review the committed code and merge to the main branch after passing review.","title":"Code Review"},{"location":"Tools/HSM-Utility/0-intro-hsm-utility/","text":"HSM Validation Utility \u00b6 Venafi TLS Protect Datacenter (formerly known as Trust Protection Platform)supports integrations with Hardware Security Modules (HSMs) to encrypt private keys, credentials, and other secrets stored in the database. Users can also use the HSM integration for the central generation of private keys. To be listed in the Venafi documentation as a compatible HSM provider, it's important to test and validate each use case that your HSM supports: Encrypt Secrets - Supports creation and storage of the Venafi database encryption key Private Key Generation - Supports creation and storage of private keys used for certificate generation Private Key Export - Supports export of private keys used for certificates Code Signing Certificate Private Key Generation & Storage Certify Your HSM Solution! Venafi makes it fast and easy to certify your HSM solution for use with Venafi. If you are interested in getting access to the HSM Validation Utility, please click here .","title":"HSM Validation Utility"},{"location":"Tools/HSM-Utility/0-intro-hsm-utility/#hsm-validation-utility","text":"Venafi TLS Protect Datacenter (formerly known as Trust Protection Platform)supports integrations with Hardware Security Modules (HSMs) to encrypt private keys, credentials, and other secrets stored in the database. Users can also use the HSM integration for the central generation of private keys. To be listed in the Venafi documentation as a compatible HSM provider, it's important to test and validate each use case that your HSM supports: Encrypt Secrets - Supports creation and storage of the Venafi database encryption key Private Key Generation - Supports creation and storage of private keys used for certificate generation Private Key Export - Supports export of private keys used for certificates Code Signing Certificate Private Key Generation & Storage Certify Your HSM Solution! Venafi makes it fast and easy to certify your HSM solution for use with Venafi. If you are interested in getting access to the HSM Validation Utility, please click here .","title":"HSM Validation Utility"},{"location":"Tools/VCert/overview-vcert/","text":"VCert \u00b6 vCert is a command line utility, SDK, and set of libraries designed to simplify key generation and enrollment of machine identities (also known as SSL/TLS certificates and keys) that comply with enterprise security policy by using Venafi. Go Python Java Ruby Since VCert enables interoperability between both Venafi TLS Protect Datacenter and TLS Protect Cloud , we ask that you test and document for each target.","title":"VCert"},{"location":"Tools/VCert/overview-vcert/#vcert","text":"vCert is a command line utility, SDK, and set of libraries designed to simplify key generation and enrollment of machine identities (also known as SSL/TLS certificates and keys) that comply with enterprise security policy by using Venafi. Go Python Java Ruby Since VCert enables interoperability between both Venafi TLS Protect Datacenter and TLS Protect Cloud , we ask that you test and document for each target.","title":"VCert"}]} \ No newline at end of file diff --git a/sitemap.xml b/sitemap.xml index 9859ba7..2d37281 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -2,257 +2,257 @@ https://ecosystem.venafi.com/ - 2023-07-27 + 2023-11-21 daily None - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/devs-glossary/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/devs-welcome/ - 2023-07-27 + 2023-11-21 daily None - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Certification/TLS-Protect-Cloud/1-tlsp-certification-intro/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Certification/TLS-Protect-Cloud/2-tlsp-certification-reqs/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Certification/TLS-Protect-Cloud/3-tlsp-certification-FAQs/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Certification/TLS-Protect-Cloud/4-tlsp-certification-submit/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Certification/TLS-Protect-For-Kubernetes/1-tlspk-certification-intro/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Certification/TLS-Protect-For-Kubernetes/2-tlspk-certification-reqs/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Certification/TLS-Protect-For-Kubernetes/3-tlspk-certification-FAQs/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Certification/TLS-Protect-For-Kubernetes/4-tlspk-certification-submit/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Design-Patterns/general-guidelines/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Design-Patterns/Cloud-WAF/0-intro-cloud-waf/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Design-Patterns/Ingress/0-intro-ingress/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Design-Patterns/Ingress/1-requirements-ingress/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Design-Patterns/Ingress/2-getting-started-ingress/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Design-Patterns/Ingress/3-functional-testing-ingress/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Design-Patterns/Issuer/0-intro-issuer/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Design-Patterns/Issuer/1-requirements-issuer/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Design-Patterns/Issuer/2-getting-started-issuer/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Design-Patterns/Issuer/3-functional-testing-issuer/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Developers/Design-Patterns/Management-Layer/0-intro-management-layer/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Getting-Started/1-how-to-engage/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Getting-Started/customers/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Getting-Started/funded-developers/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Getting-Started/general-inquiry/ - 2023-07-27 + 2023-11-21 daily None - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Getting-Started/prospective-developers/ - 2023-07-27 + 2023-11-21 daily None - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Manifesto/operating-principles/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Manifesto/statements/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Programs/devfund/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Testing-Ground/testing-diagrams/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Testing-Ground/testing-fullpage-embeds/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Testing-Ground/testing-inline-embeds/ - 2023-07-27 + 2023-11-21 daily None - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/API/overview-api/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/API/Cloud/0-intro-cloud-api/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/API/Datacenter/0-intro-datacenter-api/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/Adaptable-Framework/0-intro-adaptable-framework/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/Adaptable-Framework/1-prereqs-adaptable-framework/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/Adaptable-Framework/2-overview-adaptable-framework/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/Adaptable-Framework/3-writing-adaptable-drivers/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/Adaptable-Framework/4-submitting-your-adaptable-driver/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/Adaptable-Framework/5-managing-your-repo/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/HSM-Utility/0-intro-hsm-utility/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/HSM-Utility/1-usage-hsm-utility/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/HSM-Utility/2-Cryptoki-Use/ - 2023-07-27 + 2023-11-21 daily https://ecosystem.venafi.com/Tools/VCert/overview-vcert/ - 2023-07-27 + 2023-11-21 daily \ No newline at end of file diff --git a/sitemap.xml.gz b/sitemap.xml.gz index d41981261732820f03ba8f80d66cb47546fff189..833d597741ff0b32e3f2319130b79a6139c43624 100644 GIT binary patch literal 824 zcmV-81IPRyiwFpP`&?xL|8r?{Wo=<_E_iKh0PUGwZ<{a_hVT0;qTD+Uq?5KOO;xo@ zSFN2oHQlZqI1sDGW`usE@jT*t zwn`h@s}}5-j3LtSV-+$k$|c>4G*W1%Wk}T*CE?Zn{KY1@f*gcOZC}w4awM@(h)kE% z4Y>sf8-}-@eX*%7K^q?NfEjB@y19KI_gWbU47n643#mtpz?200)d-hHE9yL(Kg4E5 zp!;ZxA++_y*CRkX9YVuwn{eYY+*)b!IopDkU;ta+Jsq3z4k-OWO4luT0J#{1blr>x zkf(!?uGsPlkjIkTGh-|e(ikLYCPJy@8rb zS1}Il<2KEJdE5pXwvMArcTBRl9%$s2m3tma`T|iGj1%p;9a|60*s|W)se%|qK*mXvuRcwBb915=dor({9IfsIAi}M)u<#(EO@D3!%cLdkWgeK&Y@nd&i^z$znbURZ17sRoTCTp-EM=45q=HOixH~ zVym>Vy=vi>$pm5zKb8^WqFT_sNF#-ITKZIdQ4(J5&tGhkODI67%=Q(Hpg@ucg~)V8 z{g7LNuwi)X*%zDY0<_^V51Fxsr0bh|a;KGn(2xtE@`%oe5txy1zZ&7vXhpqe3;Nis z2=pIq-iNk2|9Svu$9-s+Z&Gf2hFd93KIa?I5)5GLyT?N_-ZRRem(q6&K7*Y1Li%pT zXOPFekiOXR5|Ag7+%aP;5YhxBXeLOK^9Tf&fc`Pm*^+!eU(sokH%M4VN*4PEb1f4M zh#d-Vue}ACxh$7+4Jk;2{__MR0b?u%LBq6x$bY0ciE|mcJZ3Y2&2crIzf_1h=$(O@ zOJ6ab+sAL39`pDO)NdV6nQob6Nj=cW4XgG%ldT`)|vt9ESNH)G3sXRAtL6akr7 z{hp`}b2KV-{o{vTYkyt#Y}S<@=OeNkF^tRXJ^x_I0h=!Zq5_U()tA4C7^-IT(>KNE3KT!rv*a9 zS)<-7)p0IFX6I1?=>{Ut#B=FRH(p)(a5L6gDS`C-?wYCsbitt{EaP}diW-tIViJP96{jE&H2$Rk&Lu74Ajg{})_;A(-Vawe14tStbAg D>(`X(