Bug 1890827 - Policy of kind ConfigurationPolicy Creates ConfigMap with no Data
Summary: Policy of kind ConfigurationPolicy Creates ConfigMap with no Data
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Advanced Cluster Management for Kubernetes
Classification: Red Hat
Component: App Lifecycle
Version: rhacm-2.0.z
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: rhacm-2.0.5
Assignee: Roke Jung
QA Contact: Eveline Cai
bswope@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-23 00:06 UTC by Chris Keller
Modified: 2021-04-09 16:34 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-11 22:39:59 UTC
Target Upstream Version:
Embargoed:
amcnamar: rhacm-2.0.z+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github open-cluster-management backlog issues 6464 0 None None None 2021-02-22 14:12:11 UTC
Red Hat Product Errata RHBA-2020:5095 0 None None None 2020-11-11 22:40:01 UTC

Description Chris Keller 2020-10-23 00:06:23 UTC
Description of problem:

I’m attempting to leverage a Policy of kind ConfigurationPolicy to deploy a ConfigMap resource on a cluster managed by ACM. This ConfigMap has a data attribute called ca.crt which contains a PEM encoded CA certificate. ACM is able to propagate the Policy to my managed cluster, but the data attribute (ca.crt) contains an empty string.


Version-Release number of selected component (if applicable):

Observing this behavior in 2.0.3 and 2.0.4.


How reproducible:

Whenever a PEM encoded certificate (essentially a multi-line string that begins with a hyphen) is used in the ConfigMap, the data attribute ca.crt shows up as an empty string. However, several combinations of other multi-line strings that DO NOT start with a hyphen appear to work and appear in the data attribute ca.crt after the ConfigMap is deployed.


Steps to Reproduce:

1. Add Policy resource (along with applicable PlacementRule and PlacementBinding CRs) to hub cluster via Subscription/Channel (with local placement).
2. Observe Policy resources being propagated to managed cluster. When querying the Policy resource on the hub cluster, the object-templates attribute under spec which defines the ConfigMap resource will show the data attribute ca.crt as an empty string.
3. Query ConfigMap on managed cluster and observe empty string for data attribute ca.crt


Actual results:

When deployed, ConfigMap contains an empty string for data attribute ca.crt.


Expected results:

When deployed, data attribute ca.crt contains PEM encoded CA certificate as originally defined in Policy CR.


Additional info:

The manifests for the Subscription/Channel that deploys the Policies locally to the hub can be found here: https://github.com/nasx/cluster-configs/tree/master/policy-gitops

The manifests for the Polices containing the ConfigMaps can be found here: https://github.com/nasx/cluster-configs/tree/master/policies

The specific Policy is contained in the file umbrella-acm1-oauth.yaml.

From the hub cluster, running `oc describe` on the Subscription shows the Policy is picked up and successfully placed on managed cluster acm-managed-1:

$ oc describe subscription umbrella-policy-gitops-subscription -n umbrella-policy
...
umbrella-policy-gitops-Policy-umbrella-acm1-oauth:
          Last Update Time:  2020-10-22T23:44:41Z
          Phase:             Subscribed
          Resource Status:
            Placement:
              Placement Binding:  binding-umbrella-acm1
              Placement Rule:     placement-umbrella-acm1
            Status:
              Clustername:       acm-managed-1
              Clusternamespace:  acm-managed-1
              Compliant:         Compliant
...

Querying the Policy on the hub cluster shows the ConfigMap resource with empty data attribute ca.crt:

$ oc get policy umbrella-acm1-oauth -n umbrella-policy -ojson | jq '.spec["policy-templates"][].objectDefinition.spec["object-templates"][1].objectDefinition'
{
  "apiVersion": "v1",
  "data": {
    "ca.crt": ""
  },
  "kind": "ConfigMap",
  "metadata": {
    "name": "ca-config-map",
    "namespace": "openshift-config"
  }
}

The same can be seen when querying the ConfigMap directly on the managed cluster acm-managed-1:

$ oc get configmap ca-config-map -ojson | jq .data
{
  "ca.crt": ""
}

Comment 1 Roke Jung 2020-10-23 14:46:24 UTC
There is a bug in the code that parses YAML before applying it to a cluster so the certificate content gets removed. Fixing it.

Comment 4 Roke Jung 2020-11-03 23:05:12 UTC
This is fixed in RHACM 2.0.5 and 2.1.

Comment 8 errata-xmlrpc 2020-11-11 22:39:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Red Hat Advanced Cluster Management for Kubernetes version 2.0.5 images), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:5095


Note You need to log in before you can comment on or make changes to this bug.