Cert-manager: The static manifest install option doesn't seem to work

[splashx]

/kind bug

(probably RBAC misconfig)

What happened:

$ kubectl apply -f webpage-tls.yml
Error from server (Forbidden): error when retrieving current configuration of:
&{0xc420079b00 0xc42035aa10 project-dev webpage webpage-tls.yml 0xc421bae558  false}
from server for: "webpage-tls.yml": certificates.certmanager.k8s.io "webpage" is forbidden: User "project-dev" cannot get certificates.certmanager.k8s.io in the namespace "project-dev"

What you expected to happen:

The certificate resource to be created

How to reproduce it (as minimally and precisely as possible):

As admin:

✅ Deployed the default static manifest - we don't use helm
✅ Created a ClusterIssuer

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: internal-acme-ca
spec:
  acme:
    # The ACME server URL
    server: https://boulderca.example.com/directory
    # Email address used for ACME registration
    email: [email protected]
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: acme-ca-prod
    # Enable the HTTP-01 challenge provider
    http01: {}

As a user project-dev in a namespace project-dev, defined:

webpage-tls.yml

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: webpage
spec:
  secretName: webpage-tls
  issuerRef:
    kind: ClusterIssuer
    name: internal-acme-ca
  commonName: webpage.example.com
  dnsNames:
  -  webpage.example.com
  acme:
    config:
    - http01:
        ingress: webpage-ingress
      domains:
      - webpage.example.com

$ kubectl apply -f webpage-tls.yml

Anything else we need to know?:

RBAC is on. It's not really clear from the documentation if namespaces or users need extra RBAC role configured.

Environment:

• Kubernetes version (use kubectl version):

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.4", GitCommit:"5ca598b4ba5abb89bb773071ce452e33fb66339d", GitTreeState:"clean", BuildDate:"2018-06-06T08:13:03Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.2", GitCommit:"81753b10df112992bf51bbc2c2f85208aad78335", GitTreeState:"clean", BuildDate:"2018-04-27T09:10:24Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

• Cloud provider or hardware configuration**: Openstack
• Install tools: internal/custom
• Others:

[splashx]

If you have RBAC on and install the helm chart, namespace admins will not be able to use cert-manager.

You can apply the following definitions - which are pretty sane - for namespace admin or edit roles to be able to use it.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-cert-manager-admin
  labels:
    # Add these permissions to the "admin" and "edit" default roles.
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: ["certmanager.k8s.io"]
  resources: ["certificates", "clusterissuers", "issuers"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete", "deletecollection"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-cert-manager-view
  labels:
    # Add these permissions to the "view" default role.
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["certmanager.k8s.io"]
  resources: ["certificates", "clusterissuers", "issuers"]
  verbs: ["get", "list", "watch"]

I would suggest adding a sane-default role aggregation definition (like the one above) in the helm chart - it would save time for first-timers...

[igoratencompass]

@splashx are you maybe missing aggregationRule above? Also role aggregation is valid for 1.9+ so will not work for older versions.

[splashx]

@igoratencompass I was able to make it work the way I planned by only using the above rules - no need to create a ClusterRole with aggregationRule because aggregate-to-{admin,edit,view} are existing defaults.

[munnerz]

If this is required to allow namespace admins access, then I'm open to accepting this.

However, ClusterIssuer resources should not be included in the list of things that are granted access to by default, as they are not scoped to a single namespace.

/kind feature

[splashx]

@munnerz this role will only aggregate rules. So if the admin user has a RoleBind towards a specific namespace, he will not be able to act on ClusterIssuer, because ClusterIssuer is scoped to Cluster.

We tested this in our current environment: test-admin is admin of the namespace test. Using the aggregation snippet above, even though in the aggregation rules state ClusterIssuer, namespace admins (test-admin, admin of test namespace) don't have access to it ClusterIssuer:

$ kubectl get issuer
No resources found.
$ kubectl get clusterissuer
Error from server (Forbidden): clusterissuers.certmanager.k8s.io is forbidden: User "test-admin" cannot list clusterissuers.certmanager.k8s.io at the cluster scope
$

We would have to elevate test to at least Cluster-wide view - or edit or admin. I think the RBAC rule is inline with the expectation

[munnerz]

@splashx thanks for doing the research!

It'd be great to see a PR for this then 😄 helps reduce friction for first time users!

[splashx]

@munnerz should that be treated as the createNamespaceResource (only when using static manifests) or shall I add it as part of /charts/cert-manager/templates/rbac.yaml as part of helm as a whole?

[munnerz]

or shall I add it as part of /charts/cert-manager/templates/rbac.yaml as part of helm as a whole?

I think this is the best course of action, as it is applicable to users of Helm as well as static manifests afaict.

[retest-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

[retest-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale

[munnerz]

This has now been solved in the latest version of cert-manager, so I'm going to close this issue out now 😄