I installed the cert-manager using the Helm Chart. I created a ClusterIssuer but I see that it's on a failed state:
kubectl describe clusterissuer letsencrypt-staging
ErrRegisterACMEAccount Failed to register ACME account: invalid character '<' looking for beginning of value
What could be causing this invalid character '<'?
This error is most likely the result of an incorrect server url, the url you specified is returning HTML (hence the complain about <).
Make sure that your server url is https://acme-staging-v02.api.letsencrypt.org/directory" and NOT just https://acme-staging-v02.api.letsencrypt.org/", the directory/ must be included in the url.
So the ClusterIssuer should look like this (emphasis on the .spec.acme.server)
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
spec:
acme:
email: name.surname#mycompany.com
privateKeySecretRef:
name: letsencrypt-staging
server: https://acme-staging-v02.api.letsencrypt.org/directory
solvers:
- dns01:
route53:
hostedZoneID: XXXXXXXXXXXXXX
region: eu-north-1
selector:
dnsZones:
- xxx.yyy.mycompany.com
I have the following imagepolicy:
apiVersion: image.toolkit.fluxcd.io/v1alpha2
kind: ImagePolicy
metadata:
name: cps-kul-beta-imagepolicy
namespace: flux-system
spec:
imageRepositoryRef:
name: cps-kul-image
filterTags:
pattern: '^sha-(?P<ts>.*)-.+'
extract: '$ts'
policy:
numerical:
order: asc
And I get the error version list argument cannot be empty when doing kubectl describe on that object.
This error means that there's no images in the registry which conform to the tag pattern prescribed in the filterTags section. Uploading a new image to the registry will fix this problem.
In the gatekeeper template, trying to fetch the namespace from the resoucequota object (replicated using the sync.yaml).
Currently try to fetch using :
existingrqs := {e | e := data.inventory.cluster["v1beta1"]["ResourceQuota"].metadata.namespace}
sync.yaml used :
apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
name: config
namespace: "gatekeeper-system"
spec:
sync:
syncOnly:
- group: ""
version: "v1beta1"
kind: "Pod"
- group: ""
version: "v1beta1"
kind: "Namespace"
- group: ""
version: "v1beta1"
kind: "ResourceQuota"
Not able to retrieve the namespace from resoucequota cached object.
ResourceQuotas are namespaced, so you need to use data.inventory.namespace instead of data.inventory.cluster. I can't find official documentation on referential constraints, so my best guess is you'll need something like:
existingrqs := {e | e := data.inventory.namespace[_]["v1"]["ResourceQuota"][_].metadata.namespace}
The format of data.inventory.namespace is:
data.inventory.namespace[$NAMESPACE][$APIVERSION][$KIND][$NAME]
By using _ instead of providing an explicit string, this should produce an iterator for each Namespace, for objects of API Version "v1", for objects of Kind "ResourceQuota".
I don't have a good setup for testing this, but it should get you closer to what you want.
I am using jkube to deploy a springboot helloworld application on my kubernetes installation. I wanted to add a resource fragment defining a Traefik ingress route but k8s:resource fails with "Unknown type 'ingressroute'".
IngressRoute has already been defined on the cluster using custom resource definition.
How do I write my fragment?
The following works when i deploy it with kubectl.
# IngresRoute
---
kind: IngressRoute
apiVersion: traefik.containo.us/v1alpha1
metadata:
name: demo
namespace: default
spec:
entryPoints:
- web
routes:
- match: Host(`demo.domainname.com`)
kind: Rule
services:
- name: demo
port: 80
#Rohan Kumar
Thank you for your answer. I can built and deploy it, but as soon as I add a file to use my IngressRoute, then the k8s:resource target fails.
I added files - one for each CRD with filename -cr.yml and added the following to the pom file:
<pre>
<resources>
<customResourceDefinitions>
<customResourceDefinition>traefikservices.traefik.containo.us</customResourceDefinition>
<customResourceDefinition>tlsstores.traefik.containo.us</customResourceDefinition>
<customResourceDefinition>tlsoptions.traefik.containo.us</customResourceDefinition>
<customResourceDefinition>middlewares.traefik.containo.us</customResourceDefinition>
<customResourceDefinition>ingressrouteudps.traefik.containo.us</customResourceDefinition>
<customResourceDefinition>ingressroutetcps.traefik.containo.us</customResourceDefinition>
<customResourceDefinitions>ingressroutes.traefik.containo.us</customResourceDefinitions>
</customResourceDefinitions>
</resources>
Example IngressRoute definition:
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: ingressroutes.traefik.containo.us
spec:
group: traefik.containo.us
version: v1alpha1
names:
kind: IngressRoute
plural: ingressroutes
singular: ingressroute
scope: Namespaced
But when running the k8s:resource I get the error:
Failed to execute goal org.eclipse.jkube:kubernetes-maven-plugin:1.0.2:resource (default-cli) on project demo:
Execution default-cli of goal org.eclipse.jkube:kubernetes-maven-plugin:1.0.2:resource failed: Unknown type
'ingressroute' for file 005-ingressroute.yml. Must be one of : pr, lr, pv, project, replicaset, cronjob, ds,
statefulset, clusterrolebinding, pvc, limitrange, imagestreamtag, replicationcontroller, is, rb, rc, ingress, route,
projectrequest, job, rolebinding, rq, template, serviceaccount, bc, rs, rbr, role, pod, oauthclient, ns,
resourcequota, secret, persistemtvolumeclaim, istag, customerresourcedefinition, sa, persistentvolume, crb,
clusterrb, crd, deploymentconfig, configmap, deployment, imagestream, svc, rolebindingrestriction, cj, cm,
buildconfig, daemonset, cr, crole, pb, clusterrole, pd, policybinding, service, namespace, dc
I'm from Eclipse JKube team. We have improved CustomResource support a lot in our recent v1.2.0 release. Now you only need to worry about how you name your CustomResource fragment and Eclipse JKube would detect the CustomResourceDefinition for specified IngressRoute.
I think you would need to name CustomResource fragments with a *-cr.yml at the end. This is due to distinguishing them from standard Kubernetes resources. For example I added your IngressRoute fragment in my src/main/jkube like this:
jkube-custom-resource-fragments : $ ls src/main/jkube/
ats-crd.yml crontab-crd.yml dummy-cr.yml podset-crd.yaml traefic-crd.yaml
ats-cr.yml crontab-cr.yml ingressroute-cr.yml second-dummy-cr.yml traefic-ingressroute2-cr.yml
crd.yaml dummy-crd.yml istio-crd.yaml test2-cr.yml virtualservice-cr.yml
jkube-custom-resource-fragments : $ ls src/main/jkube/traefic-ingressroute2-cr.yml
src/main/jkube/traefic-ingressroute2-cr.yml
Then you should be able to see your IngressRoute generated after k8s:resource phase:
$ mvn k8s:resource
...
$ cat target/classes/META-INF/jkube/kubernetes.yml
You can then go ahead and apply these generated manifests to your Kubernetes Cluster with apply goal:
$ mvn k8s:apply
...
$ kubectl get ingressroute
NAME AGE
demo 17s
foo 16s
I tried all this on this reproducer project and it seemed to be working okay for me: https://github.com/r0haaaan/jkube-custom-resource-fragments
i'm trying to use the EnvoyFilter to pass the jwt payload from the request, decode it and use the claims as headers to the request.
it does not work, and i fail to get the dynamicMetadata filled with the payload after using the jwt_authn.
here is an example of the jwt_authn filter i'm using:
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: jwt-filter
namespace: istio-system
spec:
workloadSelector:
labels:
app: app1
configPatches:
- applyTo: HTTP_FILTER
match:
context: SIDECAR_INBOUND
listener:
portNumber: 3000
filterChain:
filter:
name: "envoy.http_connection_manager"
subFilter:
name: "envoy.router"
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.jwt_authn
typed_config:
"#type": "type.googleapis.com/envoy.config.filter.http.jwt_authn.v2alpha.JwtProvider"
providers:
authority_jwks:
issuer: "testing#secure.istio.io"
remote_jwks:
http_uri:
uri: "https://raw.githubusercontent.com/istio/istio/master/security/tools/jwt/samples/jwks.json"
timeout: 5s
cache_duration: 3600s
forward: true
payload_in_metadata: "jwt-metadata"
forward_payload_header: "jwt-header"
i assumed that:
for the first step, if my app is printing the request headers, the jwt-header should be one of the headers and includes the encrypted jwt.
if i'm using an envoy lua filter that gets the DynamicMetadata it will includes the jwt-metadata field.
isnt it?
The JWT filter defaults to extracting the JWT token from "Authorization: Bearer " header. Do you know if Envoy is able to read it?
You can also check envoy logs when running with trace level of logging. It prints jwt_authn logs that show what the filter is doing.
i was able to solve it.
apparently the jwt_authn is used by default when using requetsAuthentication and i dont need to specfically define it on the EnvoyFilter.
what i did, was to add EnvoyFilter of lua script that gets the decryped JWT token like the following:
metadata = request_handle:streamInfo():dynamicMetadata():get("envoy.filters.http.jwt_authn") claims=metadata["testing#secure.istio.io"]
10x