Skip to content
This repository was archived by the owner on Nov 26, 2024. It is now read-only.

Commit 53d1107

Browse files
luispabonluispabon
committed
Deprecation notice. Buh-bye!
1 parent b15d1c1 commit 53d1107

File tree

1 file changed

+77
-54
lines changed

1 file changed

+77
-54
lines changed

‎README.md

Lines changed: 77 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -1,37 +1,49 @@
1+
# DEPRECATED
2+
3+
It's been quite some time now that Kong itself is capable of interfacing with Let's Encrypt to acquire certificates, and
4+
it's even easier in Kubernetes:
5+
* [https://docs.konghq.com/hub/kong-inc/acme/](https://docs.konghq.com/hub/kong-inc/acme/)
6+
* [https://cert-manager.io/](https://cert-manager.io/)
7+
18
[![Build status](https://github.com/phpdocker-io/kong-certbot-agent/actions/workflows/tests.yaml/badge.svg)](https://github.com/phpdocker-io/kong-certbot-agent/actions/workflows/tests.yaml)
29
[![Code coverage](https://codecov.io/gh/phpdocker-io/kong-certbot-agent/branch/master/graph/badge.svg?token=kwWPdOB7lQ)](https://codecov.io/gh/phpdocker-io/kong-certbot-agent)
310
[![Docker build](https://github.com/phpdocker-io/kong-certbot-agent/actions/workflows/publish.yaml/badge.svg)](https://github.com/phpdocker-io/kong-certbot-agent/actions/workflows/publish.yaml)
411

512
# Kong Certbot agent
13+
614
Let's Encrypt integration with Kong
715

8-
This repository provides with a cron-based certbot agent that will attempt to acquire Let's Encrypt certificates you control
16+
This repository provides with a cron-based certbot agent that will attempt to acquire Let's Encrypt certificates you
17+
control
918
for a list of subdomains you provide, and provision Kong with them.
1019

1120
Ideal for integrating a Kong deployment in Kubernetes with Let's Encrypt.
1221

13-
There's an example [kubernetes cronjob](kubernetes/certbot-cronjob.yml) you can use as a guide to deploy wherever you need.
22+
There's an example [kubernetes cronjob](kubernetes/certbot-cronjob.yml) you can use as a guide to deploy wherever you
23+
need.
1424

1525
## Compatibility
1626

17-
* Kong Certbot Agent 3.x: compatible with Kong 0.14 and 1.x. Kubernetes examples compatible with Kubernetes >= 1.8
18-
* Kong Certbot Agent 2.x: compatible with Kong 0.14 and 1.x. Kubernetes examples compatible with Kubernetes <= 1.8
19-
* Kong Certbot Agent 1.x: compatible with Kong <= 0.13. Kubernetes examples compatible with Kubernetes <= 1.8
27+
* Kong Certbot Agent 3.x: compatible with Kong 0.14 and 1.x. Kubernetes examples compatible with Kubernetes >= 1.8
28+
* Kong Certbot Agent 2.x: compatible with Kong 0.14 and 1.x. Kubernetes examples compatible with Kubernetes <= 1.8
29+
* Kong Certbot Agent 1.x: compatible with Kong <= 0.13. Kubernetes examples compatible with Kubernetes <= 1.8
2030

2131
## How to
2232

2333
### Run the container
24-
- The container takes 3 environment variables to operate:
34+
35+
- The container takes 3 environment variables to operate:
2536
- KONG_ENDPOINT: this will be the http endpoint your kong admin is at, without its path. ie `http://kong:8001`
2637
- EMAIL: this is the email address linked to your let's encrypt certificates.
2738
- DOMAINS: this is a comma-separated list of domains we'll be asking certificates for.
28-
- Deploy container in your environment.
29-
- It will automagically run the updater script every 24th of the month.
30-
- Profit!
39+
- Deploy container in your environment.
40+
- It will automagically run the updater script every 24th of the month.
41+
- Profit!
3142

3243
### Kong configuration
3344

34-
In order for the challenge to work correctly, you need to open up a service and a route in Kong pointing to the container at a very
45+
In order for the challenge to work correctly, you need to open up a service and a route in Kong pointing to the
46+
container at a very
3547
specific URL path. It MUST respond on every domain you're requesting certs for.
3648

3749
When it comes the time to run certbot, it will open an HTTP server, put some stuff on a specific path, then ping
@@ -41,17 +53,17 @@ This is a service definition example in Kong admin:
4153

4254
```json
4355
{
44-
"host": "kong-certbot-agent",
45-
"created_at": 1543512083,
46-
"connect_timeout": 60000,
47-
"id": "service-id-foo",
48-
"protocol": "http",
49-
"name": "KongCertbot",
50-
"read_timeout": 60000,
51-
"port": 80,
52-
"updated_at": 1543513810,
53-
"retries": 5,
54-
"write_timeout": 60000
56+
"host": "kong-certbot-agent",
57+
"created_at": 1543512083,
58+
"connect_timeout": 60000,
59+
"id": "service-id-foo",
60+
"protocol": "http",
61+
"name": "KongCertbot",
62+
"read_timeout": 60000,
63+
"port": 80,
64+
"updated_at": 1543513810,
65+
"retries": 5,
66+
"write_timeout": 60000
5567
}
5668
```
5769

@@ -61,30 +73,30 @@ Then, associate this route to it:
6173

6274
```json
6375
{
64-
"created_at": 1543512115,
65-
"strip_path": false,
66-
"hosts": [
67-
"your.list",
68-
"of.domains",
69-
"for.the",
70-
"same.certificate"
71-
],
72-
"preserve_host": false,
73-
"regex_priority": 0,
74-
"updated_at": 1543513584,
75-
"paths": [
76-
"/.well-known/acme-challenge"
77-
],
78-
"service": {
79-
"id": "service-id-foo"
80-
},
81-
"methods": [
82-
"GET"
83-
],
84-
"protocols": [
85-
"http"
86-
],
87-
"id": "route-id-foo"
76+
"created_at": 1543512115,
77+
"strip_path": false,
78+
"hosts": [
79+
"your.list",
80+
"of.domains",
81+
"for.the",
82+
"same.certificate"
83+
],
84+
"preserve_host": false,
85+
"regex_priority": 0,
86+
"updated_at": 1543513584,
87+
"paths": [
88+
"/.well-known/acme-challenge"
89+
],
90+
"service": {
91+
"id": "service-id-foo"
92+
},
93+
"methods": [
94+
"GET"
95+
],
96+
"protocols": [
97+
"http"
98+
],
99+
"id": "route-id-foo"
88100
}
89101
```
90102

@@ -125,9 +137,12 @@ docker run -it --rm \
125137

126138
### How many domains can I get certs for?
127139

128-
You can give the agent a pretty big list of domains to acquire certificates for (100), but bear in mind it will be one certificate
129-
shared among all of them. You might want to set up different cronjobs for different sets of certificates, grouped in a manner
130-
that makes sense to you. Also, if one of the domains you're getting a certificate from fails the HTTP challenge, cert acquisition
140+
You can give the agent a pretty big list of domains to acquire certificates for (100), but bear in mind it will be one
141+
certificate
142+
shared among all of them. You might want to set up different cronjobs for different sets of certificates, grouped in a
143+
manner
144+
that makes sense to you. Also, if one of the domains you're getting a certificate from fails the HTTP challenge, cert
145+
acquisition
131146
for the whole group fails.
132147

133148
### How about wildcard certs?
@@ -137,17 +152,25 @@ Due to the way certbot agent works, this will never be supported by the agent.
137152

138153
### Any considerations on a first time set up?
139154

140-
Yes. Certbot has a limit of [50 certificate requests per domain per week](https://letsencrypt.org/docs/rate-limits/) - it is very easy to go over this limit during
155+
Yes. Certbot has a limit of [50 certificate requests per domain per week](https://letsencrypt.org/docs/rate-limits/) -
156+
it is very easy to go over this limit during
141157
your initial set up while you manage to get all your stuff lined up together nicely:
142158

143-
* Use test certs initially, allowances are more generous. You can modify the command to `command: [ "/workdir/certbot-agent", "certs:update", "$(KONG_ENDPOINT)", "$(EMAIL)", "$(DOMAINS)", "--test-cert" ]` until you have everything right.
144-
* Ensure your scheduling does not retry a failed command. It's very unlikely it will succeed a second time with the same parameters
145-
and you'll go over the limit quicker than fast, especially in Kubernetes which by default will retry until your cluster goes down. The
159+
* Use test certs initially, allowances are more generous. You can modify the command to
160+
`command: [ "/workdir/certbot-agent", "certs:update", "$(KONG_ENDPOINT)", "$(EMAIL)", "$(DOMAINS)", "--test-cert" ]`
161+
until you have everything right.
162+
* Ensure your scheduling does not retry a failed command. It's very unlikely it will succeed a second time with the same
163+
parameters
164+
and you'll go over the limit quicker than fast, especially in Kubernetes which by default will retry until your
165+
cluster goes down. The
146166
[example kubernetes cronjob](kubernetes/certbot-cronjob.yml) specifically stops this from happening
147167

148168
### How often should I renew my certs?
149169

150-
By default, certbot has a limit of 50 certificate requests per domain per week as mentioned earlier, so bear this in mind. Also, certs are good for 3 months. Let's Encrypt themselves recommend once every 60 days. [The example kubernetes cronjob](kubernetes/certbot-cronjob.yml)
170+
By default, certbot has a limit of 50 certificate requests per domain per week as mentioned earlier, so bear this in
171+
mind. Also, certs are good for 3 months. Let's Encrypt themselves recommend once every 60
172+
days. [The example kubernetes cronjob](kubernetes/certbot-cronjob.yml)
151173
is setup like so.
152174

153-
You can certainly do it more often, but there's no point in spamming Let's Encrypt with extra requests - remember this is a shared resource, free as in freedom and beer, and someone surely pays for it. Be considerate.
175+
You can certainly do it more often, but there's no point in spamming Let's Encrypt with extra requests - remember this
176+
is a shared resource, free as in freedom and beer, and someone surely pays for it. Be considerate.

0 commit comments

Comments
 (0)