Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Trusted CA Bundle to Build Controller #21362

Merged

Conversation

adambkaplan
Copy link
Contributor

Read CA bundle from disk so it can be mounted into build pods.

@openshift-ci-robot openshift-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Oct 26, 2018
@adambkaplan
Copy link
Contributor Author

adambkaplan commented Oct 26, 2018

/hold

Waiting on api and client-go to settle down.

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 26, 2018
Copy link
Contributor Author

@adambkaplan adambkaplan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bparees ptal

for bundleName := range buildCAData {
caBundles[i] = bundleName
i++
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Main challenge is that if we mount the CAs by their ConfigMap key, we need to know which CAs we have prior to creating the build pod. My approach is to generate the CA data first, then pass the keys of the CA files into the build pod.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

UPDATE: If a ConfigMap is mounted with Items, it will only mount the keys referenced in the Items list. We will be mounting the service-signing-cert by referencing it's key, since we are relying on the kubelet to hold off creating the container until the cert is injected. Therefore, we must also reference the additional trusted CA by key name.

glog.Warningf("Failed to read additional trusted CA bundle %s: %v", bc.additionalTrustedCA, err)
return data
}
data["additional-ca.crt"] = string(pemData)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Failing with a warning here if the CA bundle can't be found.

TODOs:

  1. Don't log if the error is a NotFound error?
  2. Validate the data is PEM-encoded?

Copy link
Contributor

@bparees bparees left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems like a lot of extra logic when in the end we only have a single key and bundle we care about.

ultimately (when all the pieces are in place) i expect the configmap to have at most two keys:

  1. additionalCAs (optional)
  2. serviceCA

and we know that if (1) is going to be present, it will be populated when we create the configmap, so you don't have to do anything special in terms of specifically referencing mounting the key for (1) when you setup the configmap volume. You only need to do that for (2).

glog.Warningf("Failed to find additional trusted CA bundle %s: %v", bc.additionalTrustedCA, err)
return data
}
pemData, err := ioutil.ReadFile(bc.additionalTrustedCA)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should not have to read this data on every build. If the data changes we should expect the operator to restart the controller, so we can read it once during controller startup.

@smarterclayton
Copy link
Contributor

/refresh

@adambkaplan adambkaplan mentioned this pull request Nov 1, 2018
adambkaplan added a commit to adambkaplan/builder that referenced this pull request Nov 2, 2018
for bundleName := range buildCAData {
caBundles[i] = bundleName
i++
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

UPDATE: If a ConfigMap is mounted with Items, it will only mount the keys referenced in the Items list. We will be mounting the service-signing-cert by referencing it's key, since we are relying on the kubelet to hold off creating the container until the cert is injected. Therefore, we must also reference the additional trusted CA by key name.

pkg/build/controller/build/defaults/defaults.go Outdated Show resolved Hide resolved
@adambkaplan
Copy link
Contributor Author

/hold cancel

@bparees one question re: failure modes reading the CA bundle.

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 2, 2018
adambkaplan added a commit to adambkaplan/builder that referenced this pull request Nov 5, 2018
@adambkaplan adambkaplan force-pushed the buildconfig-api branch 2 times, most recently from b4a6cad to 7a2ccd0 Compare November 6, 2018 01:28
* BuildController reads additional trusted CA bundle from disk.
* Trusted CA bundle mounted into build pods via a ConfigMap.
@openshift-ci-robot openshift-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Nov 6, 2018
@adambkaplan
Copy link
Contributor Author

/retest

@adambkaplan
Copy link
Contributor Author

bump @bparees

@bparees
Copy link
Contributor

bparees commented Nov 6, 2018

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Nov 6, 2018
@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: adambkaplan, bparees

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 6, 2018
@openshift-ci-robot
Copy link

openshift-ci-robot commented Nov 6, 2018

@adambkaplan: The following tests failed, say /retest to rerun them all:

Test name Commit Details Rerun command
ci/openshift-jenkins/extended_builds e09dfaa link /test extended_builds
ci/openshift-jenkins/extended_image_ecosystem e09dfaa link /test extended_image_ecosystem
ci/prow/e2e-gcp-crio b4a6cad link /test e2e-gcp-crio

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-merge-robot openshift-merge-robot merged commit 98ffc01 into openshift:master Nov 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants