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

feat(eks): programmatic definition of kubernetes resources #3510

Merged
merged 27 commits into from
Aug 7, 2019

Conversation

eladb
Copy link
Contributor

@eladb eladb commented Aug 1, 2019

Enable programmatically defining Kubernetes resources and applying them through CloudFormation to the EKS cluster.

This enables the following:

  1. Defining additional IAM roles that can master the cluster.
  2. Programmatically managing IAM mapping through the aws-auth ConfigMap
  3. New nodes can join the cluster automatically as their IAM instance role is auto-mapped
  4. Users can now define Kubernetes resources and applications programmatically.

Sadly, in order for this to be possible, we had to use a custom resource (credits @NetaNir) in order to provision the EKS cluster. See the README file for details on why.


Please read the contribution guidelines and follow the pull-request checklist.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

Elad Ben-Israel added 4 commits July 29, 2019 09:08
This change allows defining arbitrary Kubernetes resources within an EKS cluster.
@moofish32
Copy link
Contributor

A general question here, what is thought process behind kubectl vs using a k8s client via lambda? It feels a little weird using lambda like a CLI runner, but there are some advantages. The same question starts to come with aws eks commands that are not in the SDKs.

Copy link
Contributor

@moofish32 moofish32 left a comment

Choose a reason for hiding this comment

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

@eladb

Can you talk about all the YAML parsing work? I didn't really review it, but I'm not sure exactly what drove the creation?

I left a few comments based on a quick pass.

packages/@aws-cdk/aws-eks/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-eks/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-eks/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-eks/lib/cluster.ts Outdated Show resolved Hide resolved
@@ -273,6 +361,7 @@ export class Cluster extends Resource implements ICluster {

this.addAutoScalingGroup(asg, {
maxPods: maxPodsForInstanceType(options.instanceType),
mapRole: options.mapRole,
});

return asg;
Copy link
Contributor

Choose a reason for hiding this comment

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

If a user wants to add IAM statements to the role for the worker nodes they would use this return right?

const iamEnabledNodes = eksCluster.addCapacity( ... )
iamEnabledNodes.addToRolePolicy( // special IAM permissions for managing IAM to pods // )

I've seen a lot of patterns where teams run sensitive workloads on a specific node group, that they might have previously run on master nodes.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this can be resolved. The ergonomics here are a little awkward for me. Add hands back an entity that you can't access from the class. However, I think the use case is met.

packages/@aws-cdk/aws-eks/lib/manifest-resource.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-eks/lib/manifest-resource/index.py Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-eks/lib/manifest-resource/index.py Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-eks/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-eks/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-eks/README.md Show resolved Hide resolved
packages/@aws-cdk/aws-eks/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-eks/lib/cluster.ts Show resolved Hide resolved
packages/@aws-cdk/aws-eks/lib/cluster.ts Outdated Show resolved Hide resolved
const uniqueId = crypto.createHash('md5').update(this.node.path).digest("hex");
const version = props.version || '1.13.7';

this.stack.templateOptions.transforms = [ 'AWS::Serverless-2016-10-31' ]; // required for AWS::Serverless
Copy link
Contributor

Choose a reason for hiding this comment

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

This needs a check for existing transforms and conflicts therein.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ping. This is still a recipe for disaster if people combine with other transforms, or other versions of the Serverless transform.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll add some support in Stack for this (stack.addTransform()). Let me open an issue.

packages/@aws-cdk/aws-eks/lib/kubectl-layer.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-eks/lib/kubectl-layer.ts Outdated Show resolved Hide resolved
@eladb eladb mentioned this pull request Aug 5, 2019
1 task
@eladb eladb removed their assignment Aug 5, 2019
skinny85 and others added 13 commits August 6, 2019 13:56
This adds the capability of adding a target to an event rule
that belongs to a different account than the rule itself.
Required for things like cross-account CodePipelines with source actions triggered by events.
…3487)

Our logic for trimming the length of the default IAM policy name was not working,
as it wasn't updated when logicalId became a Token rather than a literate string,
and so it was never actually triggered
(it just checked that the display name of the Token was less than 128 characters,
which it always is).
The fix is to resolve the logical ID Token before applying the trimming logic.

Fixes #3402
See CHANGELOG
Add new addContainerDependencies method to allow for container dependencies
Fixes #2490
Grants on the `alias/aws/sqs` KMS key alias are not necessary since the
key will implicitly allow for it's intended usage to be fulfilled (as
opposed to how you have to manage grants yourself when using a
user-managed key instead).

This removes the statement that was generated using an invalid resource
entry.

Fixes #2794
Fixes #3264 

I'm trying to allow a lambda function in another account to be able to invoke my CDK generated lambda function. This works through the CLI like so:

    aws lambda add-permission --function-name=myFunction --statement-id=ABoldStatement --action=lambda:InvokeFunction --principal=arn:aws:iam::{account_id}:role/a_lambda_execution_role

But CDK doesn't seem to allow me to add an ArnPrincipal doing something like this:

    myFunction.grantInvoke(new iam.ArnPrincipal(props.myARN))

With the error:

    Invalid principal type for Lambda permission statement: ArnPrincipal. Supported: AccountPrincipal, ServicePrincipal

This PR allows ArnPrincipal to be passed to lambda.grantInvoke.

There might be some additional validation required on the exact ARN as I believe only some ARNs are supported by lambda add-permission
jogold and others added 2 commits August 6, 2019 13:57
* rename `KubernetesManifest` to `KubernetesResource` and `addResource`
* move AWS Auth APIs to `cluster.awsAuth` and expose `AwsAuth`
* remove the yaml library (we can just use a JSON stream)
* add support for adding accounts to aws-auth
* fix cluster deletion bug
* move kubctl app info to constants
@eladb
Copy link
Contributor Author

eladb commented Aug 6, 2019

@moofish32 @rix0rrr can you please take another look? I think I've addressed most of your comments.

Copy link
Contributor

@rix0rrr rix0rrr left a comment

Choose a reason for hiding this comment

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

Provisional approval, do what you will with my previous comments :). How does that work these days?

@rix0rrr rix0rrr added the pr/do-not-merge This PR should not be merged at this time. label Aug 7, 2019
rix0rrr
rix0rrr previously approved these changes Aug 7, 2019
@eladb eladb removed the pr/do-not-merge This PR should not be merged at this time. label Aug 7, 2019
@mergify mergify bot merged commit 4e11d86 into master Aug 7, 2019
@RomainMuller RomainMuller deleted the benisrae/eks-kubectl branch August 10, 2019 00:38
@NGL321 NGL321 added the contribution/core This is a PR that came from AWS. label Sep 23, 2019
@mergify
Copy link
Contributor

mergify bot commented Sep 23, 2019

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist
:

  • PR title type(scope): text
    • type: fix, feat, refactor go into CHANGELOG, chore is hidden
    • scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
    • text: use all lower-case, do not end with a period, do not include issue refs
  • PR Description
    • Rationale: describe rationale of change and approach taken
    • Issues: indicate issues fixed via: fixes #xxx or closes #xxx
    • Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
  • Testing
    • Unit test added. Prefer to add a new test rather than modify existing tests
    • CLI or init templates change? Re-run/add CLI integration tests
  • Documentation
    • README: update module README to describe new features
    • API docs: public APIs must be documented. Copy from official AWS docs when possible
    • Design: for significant features, follow design process

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS.
Projects
None yet
Development

Successfully merging this pull request may close these issues.